Hi there and welcome to this bonus course. Video on insecure de serialization, insecure dc de serialization first is a hard word to say, and second is still a very relevant security risk in the world today. This was not included on the 2021 Watch top 10 list, but it was included on previous lists. And so we wanted to offer an opportunity to still explain what this is. Give a technical, you know, dis discussion and definition of this and show you some examples those kinds of things. So the video you're about to watch was actually recorded previously on a previous Watch top 10. But like we said, it's still a very relevant security risk today. So I hope you enjoy this video on insecure de serialization. And if you're anything like me, the first thing you ask yourself is what in the world is insecure de serialization. I think this one takes the it takes the prize for the most complicated title, you know, certainly the most the title with the most syllables, right? But but nonetheless it's on here. We're going to talk about it and we're going to figure out what this thing is. All right. So let's dive right in in order to know what insecure de serialization is. Let's first talk about de serialization itself. So what is the serialization? So, serialization sort of back up, it's kind of several, several layers deep, I guess. So to start with serialization, it so you can see there's the process of turning some object into a format that can be restored later. So this is you know imagine you have like a you know some kind of a state of an object on a web service or web application. Let's say you're shopping on you know some online marketplace and you want to save your cart you know the items in your cart and then you come back later and you want those to still be there. Right well something needs to save that somewhere or let's say you're playing some you know online game and you you know you reached your high score and it's like man I don't want to lose that but I gotta log off right now but when I come log back on then I want my you know I want my max score to still be saved, right? So So anyway so a lot of times the end of the state of the objects you want to you want to maintain that. So serialization takes takes the object, turns it into a data format that can be restored later. And people people serialize objects in order to save storage. It saves on space, that kind of thing. It's it's it's a lot it's it's fast to send serialized data like byte stream, you know data back and forth between different devices. So anyway so people will serialize data for a number of different reasons. Also it's you know it's it's from a compatibility perspective if you have one service or one device that can read you know data in one format and then you want to send it over to a different one and that's going to need it in a different format. The question is, well how do you get it over there? How do you you know, move it from one format to another? And the answer is a lot of times people will serialize it into a common format and then de serialize it you know back into the format that the other service or the other you know, device can read it in. So anyway, so so serialization is the process of turning an object into a format that then can be rebuilt and restored later. So of course de serialization is the reverse of that. So it takes that you know the data that's structured and it rebuilds it into the object that it once was before it got serialized. So you can see there in that second bullet, the most popular data format for serializing data today is Jason. It's the javascript object notation is what that stands for. Sure many of you have heard the term Jason or maybe you know a lot about it. It's a certain data, you know, format. So so anyway, but that that's today that's the most popular before, Jason really got popular than xml was the it was probably the most popular format for serializing data. But nonetheless it's a it's out there. So that's serialization and then de serialization. So again, turning object into a format that can be restored later civilization. De serialization is the reverse of that process. You know, turning it back into you know, the object. And so you can see that last bullet there, developers typically know to sanitize normal user input. The reason that they know this just inherently is that you know, typical user input should be untrusted, you know, because you just, you have no idea what a what a standard user is going to, you know, send to your web application. So it could be, you know, very normal, very good input, but it could also be very malicious from an attacker or whatever. So, so, you know, don't ever trust user input, I guess it's a good general term. And so a lot of developers know to do that. So they'll sanitize, you know, typical user input. However they sometimes they forget about sanitizing objects and so, you know, they look at, hey, here's a here's a serialized object. And that's going to be de serialized later and they sometimes developers will forget that hey, that could also be manipulated. So I need to sanitize that stuff as well. So don't don't necessarily inherently trust you know, objects as, you know, as well. So you, you need to sanitize those also. So what Attackers will do is they will, they will take advantage of the fact that sometimes developers will inherently trust objects. And so they'll use that to exploit that inherent trust, and they will slip malicious stuff in there. And and then they'll be able to kind of slide by what would have been, you know, some security practices and methods and, you know, processes and all that stuff, and they'll be able to to, you know, inject malicious you know, content into your web applications. So anyway, so that's so that's just kind of a good good idea to keep in mind as a developer or just in general, if you kind of wanted to know, you know, hey, what's the big deal with, you know, insecure de serialization? It's because, you know, to at least at least in part it's because, you know, developers sometimes we'll we'll forget to sanitize objects. So, anyway, so that's a little bit about serialization. And then of course, de serialization, I wanted to show you a quick like, C Sharp example here, and this is this is some c sharp code, of course, I'm going to use my mouse pointer here a little bit to kind of go through this. So you have some functions that are, that are, you know, defined here, you've got some different you know, variables, that kind of thing. But I guess what I want to call to attention is this like product dot name, product dot exploration product dot sizes. And so you're defining like the name of this product is Apple. The exploration of this product is you know, this date format december 28th of 2028. And then the size of this product is it's a string format and it is size small. Alright, and then there's other code that would call different things or define different things whatever, I didn't put all of it in here. But nonetheless you're doing some things, you know some defining of some variables and setting, you know setting definitions and values and all that kind of stuff here. And then a little further down you're going to define this variable called Jason. It's a string Jason and it equals it's calling this convert Jason convert to serialize object. The this object back up here. And then finally you want to write to the console this variable Json. So, the question is you know what? When I write this variable to the console, what is the console going to have in it and I've listed it here. it's going to put it in these curly brackets with the quotation marks and then the name and then it has this colon in the middle with a comma that that separate the various parts and pieces. But you can, you'll notice here that all of this can tie back or does tie back to this code up here, so like the name is Apple. So, down here name is Apple. Expiration is this date, expiration is the date, sizes is small, sizes is small. So what's happened here? This is in Json format right here, kind of in a horizontal orientation. You can also list this vertically but it's just the way that was printed out here is horizontal, it doesn't really matter. But this right here, is a Json format of this data and so it's, once it goes through the serialization process, then it put it in this different format, then it can be sent over to another service or another device. Whatever that would maybe recognize or be able to read this format or at least know to then take it out of this and put it back into whatever code that it would need that it could use it in. So anyway, the point is with the serialization and deserialization, their objects or this data is taken from one structure down to a common byte stream frankly format. And then sent across to a different service or a different device and then it's kind of rebuilt on the other side via deserialization. So anyway, so that's a little bit of an example of what that might look like. And I wanted to show you next really quick the OS literature. I know we've gone through each one of these and these courses but this one it's interesting obviously, it's number 8. So, you look at all the different scores on the different things. But one thing I wanted to point out here is, right here in the middle, this issue of insecurity serialization is included in the top 10 based on the survey and not on quantifiable data. So this is, I believe the only one that's like that on the top 10. So that's an interesting thing and if you remember back to the overview of course that we did, we talked about this survey and just how the OS comes up with the top 10 and just all that stuff. And all the different inputs that are considered and all that different stuff. So of course based on those inputs, then the top 10 is developed and this one specifically is included because of the survey of the respondents to the top 10 inquiry. So anyway, to go through the different parts and pieces of this table, the exploit ability here gets a 1. You can read there, the exploitation is somewhat difficult because it takes a little deeper knowledge or a little more complex understanding to actually exploit a serialization vulnerability. So that's why that gets a 1. So it's hard to exploit this thing. The prevalence is a 2. It's pretty widespread, it's pretty prevalent out there in the world today. Detectability is also a 2. It's not that easy to detect but it's not that hard either. And then, but the technical impact you can see there's a 3. So, the impact could be, any number of things and we'll look at a couple of examples here in just a minute, but it could be everything from stealing sensitive data to remote code execution. So, now an attacker may have access to your system and is remotely executing code. So it depends on the exact details of the attack, but the technical impact could be very significant with this security risk. So anyway, again, you've put all these different numbers into the formula that the OS uses, you crank out the results and then insecurity serialization lands at number 8. The one other thing that I would mention about this one is that this is brand new to the top 10 list. It has never existed there before and so suddenly it's number 8 on the list on this most recent 2017 version. So, kind of an interesting thing there. I guess some people may assume that if a brand new risk is going to hit the list, it's probably going to be number 10 or something. But this one has jumped up at least the number 8 even being brand new. So, it's one to keep an eye on and certainly to consider. So anyway, alright, so I wanted to get into an actual example of what this might look like. And this is maybe a java example if you've got java code and you've got that running, you got a java virtual machine running as part of your web service and there's these class paths that are part of that. So, let's say that this vulnerable web service or this web service in this case it's vulnerable of because that's our example. Let's say that it expects a certain class to be included with. Let's say there's a maybe a cookie that is sent to this web service. And the cookie has certain parts and pieces and conditions and all of that. And this application or this web service, expects certain things to be a part of that cookie. And it expects certain classes in this case to be a part of that cookie. Well let's say, that an attacker can manipulate that cookie and send it an unexpected class. And so, if the attacker serializes the input of this cookie for example. And, but it includes a different class than what this web service is expecting. So, let's just say for example that the web services expecting some user state information in this cookie. But let's say instead, the attacker includes maybe some kind of a database connection information or database connection class instead. So, the vulnerable web service in this case, would receive the input of what it thinks is some user state connection cookie. And it's going to process it as such and it just blindly deserializes that input. And it deserialize it into the state of what it thinks is some user state connection cookie. But as it deserializing and I just kind of build this out a little bit deserialize it expecting a different class. But then, the java virtual machine is then going to run whatever the class actually was from the malicious serialized input. So again, if it expected some user state information in this cookie, but the actual serialized input contains some kind of database connection. information, then what what is going to actually be run or the class is going to be called? Is the database stuff right? Because the vulnerable web service just blindly de serialized it and send it on to the virtual machine in this case. And then the virtual machine is going to run the class that was actually included back here from the attacker. So when it does that, unbeknownst to this vulnerable web service, this java virtual machine runs the unexpected class. Well, that unexpected class and this is exactly what the attacker was trying to do. That unexpected class has some kind of method that it calls, but it but it ends up being some malicious method because the attacker has manipulated that to be malicious in nature. So, so now the so some method gets called that includes, let's say some kind of remote code execution, you know, capability. And so essentially what the attacker is doing is it's saying, hey, I know that if I can send in malicious serialized input to this vulnerable web service, that ultimately I can get this unexpected class to run. And then that will call this method that I can manipulate to then maybe run some kind of remote code, execute a ble or that kind of a thing. So, so anyway, so that's the that's kind of the heart and soul of this. And that is again, if this web service just blindly de serialize is and sends it off then in this case the java virtual machine is going to you know, run this unexpected class and call this call this method that ends up being malicious in nature because of what the attacker has done with it. So anyway, so that's, that's one example of an insecure de serialization situation. And then one other one that I would go through as well is let's say you have an online marketplace. You know, I talked about this a second ago where it's like, hey, you know, I'm, I'm over here and I'm user john and I'm, you know, put this iphone in my shopping cart and it costs 900 bucks or whatever. You know, which, which frankly, for an iphone today is not that unheard of. I guess it's it's kind of amazing how much Apple can charge for their iphones. But frankly this is a little tangent. The reason they charge that much is because all of us consumers pay that much and we, we pay it all the time. So then that's why they keep charging it. But anyway, nonetheless, soapbox over. Right. Okay, so let's say that this, that this object gets put into this format as I've sent it into, you know, the market dot com. You know, website or web application. And then it gets, you know, put back into, you know, the, the, the serialized or that it gets serialized and then de serialize, let's say this is just a very very basic example. And so here's my, here's my user state and all that on the web application. Right? Okay. Well let's say that this that this market dot com web application web service also has a sequel database tied to it. Right? And let's say that this same information that gets sent over may ultimately get turned into a sequel. You know, statement where it's going to say select star from item where user equals and then it's going to use market dot user. So basically it's saying you know, this object right here is going to say when it says market dot user basically it's saying, hey, what's the user name of the usual that we're talking about here and it wants to know it's going to say select everything there select everything from the items that that user has basically is kind of what's going on here. But nonetheless, it's using the actual input from the you know, serialized you know, data right here as input into the sequel statement. Alright. So if an attacker can do a bunch of, you know, really, really good you know, digging and research and all that and understand that this is what's going on on the back end or maybe even just have a really good guess that this is what's going on in the back end. Then a malicious user could come in and say, hey, which by the way, let me look at this. So let's say that I have an iphone currently, but let's say I had stored some shoes before that, you know, on this marketplace and maybe I have other things, whatever it is. So the select statement would just give a list of all the different items that I have as user, you know, jOHN okay. So let's say an attacker comes in and says, hey, I'm going to put in this, you know, sequel injection. This whole, you know, this is kind of your standard, basic, you know, single parentheses or single quote, you know, or one equals one kind of a thing. So that now the user equals that. And so then as this gets rebuilt on the web application, now the user's name is not jOHN anymore. The user's name is, you know, quote or one equals one. And then the item is still iphone that costs still 900 bucks, whatever. All right. Well then again, if that gets used later on, in some kind of a sequel command then now instead of jOHN being put into that sequel command now it's select star from item where user equals, you know, this, blank space or one equals one. Well, you know, if you, if you watch the injection, the number one course that we did here in this, this whole skills learning path. You know, we talked about different sequel injection, zelda injections, that kind of stuff. But anyway, basically this is a true statement because either this is true or this is true and one always equals one. And so this part of this whole boolean operation is true. Therefore this whole thing is true. Therefore this will log in, but it's not just for user john at this point now it's for, you know, every item from every user in the database because it's select star from item, you know, where one equals one. So it's like, well one always equals one. So just give me every give me, you know, star from item period. So anyway, so it's just going to dump a whole bunch of information you know, back to what would be the attacker in this case. And and so then that's of course not good. So this this is this certainly, you know, gets to the heart of of the serialization and in de serialization process, some would say. And I think rightfully so that this this is this is also obviously an injection attack. This could be, you know, you know, more more of a, you know, security access or that that type of situation going on right here. So it may it may not be the best example of insecurity civilization, but it also but it does get to the heart of hey, data is serialized and then de serialized and as it's de serialized if it's not sanitized, then it could it could do bad things. It could run, you know run commands that don't need to be run or that kind of a thing. So anyway the job example I gave before is probably a more clean crisp example of insecurity de serialization. But this one also you know shows the effect of what could be done with serialization and then ultimately obviously de serialization. So so anyway, so as we look at this, you know, you ask yourself are you vulnerable? Is your web application vulnerable? And the answer is if you deserializing de serialize hostile or tampered objects then you will be vulnerable. Right? So so this is where you have to look at the sanitization of objects, you know that we talked about at the very beginning. So a couple of different attacks that we've kind of just talked about here, object and data structure related attacks attacker modifies, excuse me modifies logic achieves remote code execution. This is where the classes that are available to an application or that web service that we talked about with the hey I thought that this was user state. Some user state object but turns out it's a database connection object and there was a class that was available to the application. And then the application just blindly runs it because that class was actually available. Maybe the attacker, again did some reconnaissance and some research work to figure out that hey this classes available. So that's why I'm going to use it in this maliciously, malformed cookie, serialized input like we talked about before. So anyway, so that obviously can happen and then and then data tampering attacks just like what we talked about a second ago, you know access control related. That's like I said before, maybe it's not strictly insecure deserialization, it's more access control or injection, that kind of thing. But nonetheless, that's those types of things can happen via an insecure deserialization attack. So anyway, content has changed, that's where you start getting into databases. You can drop tables, you can delete stuff, you can add stuff, you can do all kinds of stuff that so you're talking about changing modifying, deleting, adding all your content. That's not good of course. And then you can see down there serialization may be used in applications you can see the different things there, different web services. Cashing, and persistence, this is kind of goes back to the, let me save the state of some object that holds my shopping card information. Or my like I mentioned before some kind of online gaming high score that you wanted to have or that kind of a thing. So those are some examples you can see the rest with databases and different cookies and parameters and tokens, that kind of a thing. So anyway those are just things to keep in mind in terms of what would an application use serialization for to begin with. And then of course, if it uses serialization then you've got the deserialization component of that as well, which then opens you up to the possibility of insecure deserialization. So if there's any kind of serialization stuff going on, you just need to be aware that this one is out there and you need to protect yourself and this is how you can do some of those things. Some things to keep in mind, you can see there the the only safe architecture is just don't accept serialized objects from untrusted sources. Or you can use serialization mediums that only permit primitive data types. So things that would not potentially run some malicious code. If you cannot do that, then here are a few things you can do, integrity checks, like digital signatures on serialized objects. So this gets back to maybe the data tampering or that SQL injection thing that we looked at. If you have a digital signature, then that would obviously alert you to any kind of edit or change in the serialized object. And so then as you deserialize it, if the signatures don't match that kind of a thing, then it's like, okay, this is not right, so just discard that kind of stuff. So anyway the second one there, the enforcing strict type constraints during deserialization. Code typically expects a defined set of classes. This gets to the heart of that Java example that we had before, the web services expecting a certain set of classes with a certain object. And if a different set of classes is actually delivered to that web service other than the expected defined double set of classes, then that's not good, right? So you can lock that down and say, hey let me make sure that I'm enforcing type constraints on the deserialization side of that. The next one there, the running code in low privileged environments. This is just a good idea in terms of hey, let me run the code in an environment that is necessary, but let me not run it in some highly accessible environment. Or highly classified or just that kind of a thing, so that if anything malicious happened to be there, then it's not going to be able to spread and get into some really highly sensitive environment. So anyway, so that's just kind of a good overall idea. Logging failures is a good idea. Going back to that job example that we had interestingly enough, there would be a failure or an exception flag that would have been trip, that would have been shown. But that would not have happened until after the damage was done. So the code would have run and all that, but then it would have been like, hey, wait a minute, this is not the class I expected or whatever. And so to log those exceptions and failures will give you an idea that it's like, my gosh, if some exception is logged. Then that could alert me that someone has tried to do some nefarious thing like we talked about in that first example. And then that would let you know that hey this could be happening to me. So logging is very important. So anyway that's a good thing. You can monitor and restrict incoming outgoing connectivity. The servers containers that deserializing just limiting your the impact of what deserialization could do. And then monitoring again the deserialization, if a user is constantly deserializing then it's probably not because this user just loves deserialization so much. It's because they're trying to do something nefarious and wrong and all that. So monitor that stuff. If you've got a user out there just constantly doing it, then keep an eye on that user and maybe block them or do what you gotta do to shut that down. So anyway, the last thing I've mentioned there is of course the cheat sheets that we that we mentioned on just about every one of these. The OWASP has a great cheat sheet on deserialization. It gives some really good practical tips on what you can do and what to look for, what to avoid that whole thing. Good definitions on what serialization deserialization is. And it looks at a lot of different programming languages, a lot of different code samples on, hey, in Java, here's what it looks like in PHP. Here's what it looks like in all that stuff. So it's just a great place to go look and kind of give yourself a good checklist of things to look for as you build out your own web application. Or if you already have your web application, then maybe go back and check and make sure that you're following some good best practices. So that's always a good thing to look at. So with that we will wrap up this course on insecure deserialization. I hope you've learned a couple of things. Again, this it's maybe a harder one to say insecure deserialization. A lot of consonants in that thing or a lot of syllables, whatever. But nonetheless, it's out there, it's important, it's new to the list. And who knows, I mean, it may grow the next time this list comes out. It may be even higher on the list. So, it's good to understand at least the basics of what it is and keep yourself safe from any kind of insecure deserialization attacks and vulnerability. So thanks for hanging in there with us today on this course and come back next time for number nine. We're almost there through the whole OWASP top ten. And I hope you have a great day.
