Check out a free preview of the full Web Security, v2 course
The "Parameter Injection" Lesson is part of the full, Web Security, v2 course featured in this preview video. Here's what you'd learn in this lesson:
Steve discusses privilege escalation in applications that use NoSQL databases. He emphasizes the importance of implementing allow listing instead of deny listing to prevent such attacks. He also demonstrates how an attacker can manipulate request parameters using tools like cURL or the browser's network tab.
Transcript from the "Parameter Injection" Lesson
[00:00:00]
>> Steve Kinney: There is another way to do privilege escalation in this app as well. We're using SQL ,right? But a lot of apps whether they be JavaScript apps otherwise will sometimes use a NoSQL database which is effectively JSON under the hood, which we can think about as JavaScript Objects, right?
[00:00:18]
And one of the attack vectors there is a little bit different than trying to put something in a string, right? A lot of us who have written front-end code before will see something like this where it's like object and it's like, sure, no.
>> Steve Kinney: {a: 1, b: 2, c: 3}, and I wanna say const extended = {...object and, like, admin:true}, right?
[00:00:47]
Or maybe that's not actually what the code is doing but if you're spread operating all the properties from one object onto another you can do this in Mongo. You can do this in CouchDB, you can do this a lot of NoSQL databases as JavaScript objects, and if someone can slide an extra property in there, then they can theoretically change stuff that you did not intended.
[00:01:09]
And honestly, that one's on you it's not like, they were super clever it's just you were blindly allow listing everything. One of the key ways to keep yourself secure is,it's not deny list. It's not saying it has admin, then don't let it in cuz, well, they'll find some weird way to put a back tech in there and I'll get through, right?
[00:01:27]
It is basically like, no, for this request, we allow list a certain number of properties and everything else is not allowed, right? So if you find yourself doing like this, you're going to like no library is gonna save you from this, all right? And there's some really interesting attack vectors around privilege escalation, I'm using SQL, so I made a fake version of this.
[00:01:51]
And if we go look at posting to the user profile or I think patching it, right, cuz a patch HTTP method means I want to update only some properties on this object, right? Obviously, post means make a new to-do item, right? Put means completely updated, Patch means change a few properties.
[00:02:15]
Now we all abuse HTTP methods and we use them wrong and there are reasons why we do that. For instance, in the browser, you can say that a form has a method get, you can say post, you can try to say any other one, but it's like the browser performs only supports get and post and not all the HTTP methods.
[00:02:34]
You can only use Patch and Delete and the other ones with like Fetch, whatever. So we all tend to abuse the verbs, but if we're being intellectually honest, right? What I just wanna do is take whatever comes in from the body and update the user with those params.
[00:02:51]
And that seems legit, right? So for instance, if we went back to the core app, we went to the Profile and I don't need this open for a little bit, we can zoom out slightly. I can go update stuff about myself so we can become Bobby Tablets. I included one additional field in here for a later example that then I broke.
[00:03:22]
>> Steve Kinney: That one right there get out of here.
>> Steve Kinney: Bobby Tablets.
>> Steve Kinney: All right, cool. So now if you look, I can change this name from Bobby Tables to Bobby Tablets and I did that a second ago, so I can actually say, let's change it to Robert. He's decided as he got older, he's gonna go by his full first name that's great, cool.
[00:03:52]
And I refresh you can see it persists in the database, but if we are doing that kind of extending pattern that we sometimes do from habit, especially if we've written a lot of react, right? We're like, immutable data structures, yeah, right? We tend to bring that wherever we go, and all it takes is someone going, I think I'm gonna inspect element over here.
[00:04:19]
What if we said, instead of Name, this one was like Admin we'll go, we'll say the Name of this property is really admin, and we'll say the value is like, true, right? And it's gonna take all those request body things, cuz it's making a JSON object. And if we scroll up and we refresh, look, we just privileged escalated ourselves to administrator, right?
[00:04:42]
Because, again, we blobbed on the object they guessed that there was a field called Admin that was true. Other thing I would probably guess is probably role seems like a good one and maybe you don't succeed. A lot of these things are again, when we look at some of the famous attacks, it was, I kind of noticed a thing.
[00:05:01]
And that led me to notice another thing, and that led me to notice another thing, and that led me to the FBI at my house, right, literally. And so those are usually how these go but the solutions on our end are Lala's work, right? And so again, that the solution to this is very simple, it's basically, kind of in the cases of .patch for the Profile, right?
[00:05:35]
Instead of grabbing everything from request.body, you could say let's say, assume this thing only let you change the name, right? I could grab the credit card and everything else and it's not important. So we could say like, for instance, name, right? Even those right name, email and body, and then only pass these in.
[00:06:02]
>> Steve Kinney: Cuz again, this is what I was talking about forward with this idea of allow listing, right? Where no longer are we letting them take anything. They can pass an admin, they could pass in whatever they want. They can try to change their address in this form now to their address and try to order stuff, even if they did get the thing.
[00:06:19]
This case, we are only allow listing these things. So now, trying to use the same attack wouldn't go anywhere, it would just fall into the void, right? And no library is gonna save you from that, right? That is a tiny little thing that hopefully, like even a code review, no one's gonna catch that in the code review, right?
[00:06:36]
This is where that kind of thinking about some of the principles of how we architect things, and to give us some mind to go looking for it. But no code scanning tool, or thing is gonna detect that for you. And I think that's kind of one of the key pieces here as well.
[00:06:53]
And again I could do this with the form. Let's say there wasn't a form I could get a curl command, right, for funsies, if you ever want, you can go to the Network tab and you can grab any request that makes you happy and you can do copy as either curl as a fetch command and you can tweak all the different params to anything you want, right?
[00:07:16]
Cuz again, the good part of the web is that they don't need to install anything. The bad part is effectively whoever's on the receiving end has access all your code, right? And so they can theoretically grab these tweak them, and there's nothing wrong with that per se as well.
[00:07:36]
But knowing that it is on your responsibility to then defend code defensively.
Learn Straight from the Experts Who Shape the Modern Web
- In-depth Courses
- Industry Leading Experts
- Learning Paths
- Live Interactive Workshops