Hi, everyone. Welcome back to the course. So in the last module we talked about cross site scripting. We talked about the differences between reflected and stored cross site scripting.
In this video, we're to talk about insecure D serialization.
So that's a quick pre assessment question here, and it's actually a very easy one. So Insecurity, Sara de serialization Excuse me, is the most common vulnerability in the old lost top 10. Is that true or false?
That's false. Actually, we'll talk about the actual
prevalence of this particular vulnerability.
So we're learning objectives for this video. We're gonna talk about the risk rating like we've been doing. Well, kind of touch on that a little bit we'll talk about. We're actually gonna talk about what serialized ation is. So that way you can understand what insecure D serialization is
we're gonna talk about as I mention the prevalence, how to check for this as well as different prevention or mitigation
options that we may have.
So you'll notice here that if this can actually be exploited, this could lead to things like remote code executions. You'll see the technical impacts is actually the red, or as we know the bad stuff, right? The critical stuff,
Uh, but we noticed that the prevalence is just common now.
One thing with this, the prevalence is actually common, based off of an industry survey that all lost. It is not actually like quantifiable data from the field. So there's one of those weird ones that may drop off the list the next time around, once they hopefully get some data on it.
And it's very challenging to exploit. It requires, even with, like, tools that are all kind of off the shelf exploits, as we would call them, even with those that normally requires some custom tweaks to the exploit code to actually make these things successful.
So what is serialization? We'll talk about that first, and then we'll talk about dearest, the serialization. So all serialization is It's a basic of the process of converting an object into a byte stream, as you see in the graphic here. And then D. C. Realization has just taken that that byte stream and converting it back into an actual object.
they have states and behavior. So think of him like a cat, for example, like with cats, we've got different breeds of cats. You know, you have a tabby cat or a short hair, you know, our domestic long hair, whatever the case might be,
and then all those types of cats and based on their Obree, they're gonna have different behaviors. Right? So, for example, I've got, like, a domestic shorthair cat on, and she's pretty lazy and doesn't do a whole lot. But I've had tabby cats in the past and the very exciting and they're playing all the time and getting it stuff, etcetera. So
think of that and kind of correlate that with an object, right? So the objects, they're gonna have different behaviors. There's gonna be different types of objects. And so that's what we're talking about when we refer to in object. Now, we're not gonna dump, jump into programming languages at all or any type of programming at all. But just so you understand, like when I mentioned the word object, that's what we're referring to.
I think you've collected the cat example where
every time every breed of cattle cat is an object, right? And then we've got different breeds of cats, which would be like our states, you know, So are different. Breeds are different states then, based off those breeze, we've got different behaviors of how the cat's act or how the objects act
prevalent. So as I mentioned this, everything is basically based off a survey that loss did. Then. That's why this one is on the top 10.
So it's it's common based off the survey, as I mentioned already, there's really no data from the real world, and it does require an attacker to do a lot of manual work. So it's not something that you'll necessarily see exploited a whole lot.
And even here, regardless of industry, you probably won't see it exploited in the wild a whole lot.
So how do we check for it? Well, manual review is actually probably the biggest factor. Um, and then, of course, property Lee sanitizing our data. But many review is probably the biggest thing, because we have to look through it, actually, look at the code and see if it's potentially vulnerable to this
and then data validation, you know? So isn't data what it should be? Are we seeing manipulated data, as you know, is the data tampered with it all, you know, so for example, on things like accident access, control related attacks. That's where you know, we were gonna use that existing data structure, but the content itself might be changed.
So what kind of impact I mentioned that, you know, if someone can actually pull this off, it can lead to, like, remote code action, execution eso things, you know, related specifically to the object in data structures, data tampering, as I mentioned before
and then also, an attacker could potentially use this for things like replay attacks, injection attacks, which we've already covered in this course and privilege escalation and et cetera, et cetera.
So prevention, what can we do to actually prevent against this stuff? Well, number one doing integrity checks on the objects. So using things like digital signatures
also isolating the code
when it's running, logging, decentralization failures were exception. So logging that and then setting a monitor for that So we get an alert when that that's transpiring
and one of the bigger things is encrypting serialized data. So as we convert it into the bites dreams, go ahead, encrypt it that way, when it's transmitted and we decrypt it, there's no alteration in that stream before we can actually open it up and take it back to Justin. Object.
So a quick post assessment question here,
John is looking for ways to reduce the likelihood off insecure decentralization vulnerabilities
which the following is not something he could do to effectively reduce the risk of vulnerabilities.
So which one of these is that?
All right, so if you answer D you are correct. So again, you're just using serialization is not a way that, in Web service is is not a way that will effectively reduce the risk of these vulnerabilities. However, using on the sea allies objects, enforcing type constraints. So basically the code expects it to final set of classes.
And so we just make sure that whatever input is coming in,
it matches those particular constraints and then isolating the code as well that we talked about before.
So in this video, we talked about insecurity, serialization and our lab. We're gonna take a look at an example of that, and then we'll move into module 10 where we talk about using components with known vulnerabilities