Hi there. I'm John, and this is the InfoSec skills learning path for the 2021 OWASP Top 10, and this is security risk number 3, injections. Let's talk about injection today. Injection which frankly used to be number 1 on the OWASP top 10 list for many years now finds its way on to number 3, there's a couple of factors there. Number 1, injection is not quite as big of a risk anymore these days, it's still big because it's number 3 but other problems are even bigger as it were. It's not that injection, is not a big deal, it's just other things are even bigger deals. But nonetheless, injection. What is injection? Injection attacks or injection risks allow attackers, you can see there in the top bullet, they allow attackers to relay malicious code through an application to another system. There's malicious code that's being sent to some back-end system component of your application. You can see there, calls to the operating system via system calls or the use of external programs via shell commands, calls to back in databases like SQL injection. Those are all injection type, that's what injection is all about. If an application uses some an interpreter, then there's danger of introducing an injection vulnerability, this injection attack. I would point out, I'll probably say this more than once but the most common type of injection that you'll probably hear about is SQL injection, but SQL is not the only type of injection. In fact, we will look at a couple of different examples of different types of injection attacks here in this video. That's injection. The thing about the factors with the OWASP top 10 for the 2021 for injection are laid out here. There were 33 CWEs that were mapped to injection risks, injection vulnerabilities if you will, and then the max incident rate was 19 percent, 19.09, and the average incidence rate of applications that were actually vulnerable to the CWEs, the max was 19, the average was 3.37 there you can see. Those are not quite as big as some of the other ones that we've seen so far which like I said, injection is not as big of an issue because a lot of browsers, a lot of web application development has found ways to protect against this a little bit better. People are getting better at coding which is good but it's still a problem. You can see the average weighted exploit, what is the exploitability? 7.25, again that's out of 10. Then, the impact is 7.15. That's a big, especially for averages. Frankly, what that's telling us is these are pretty easy to exploit and they're pretty devastating, they're pretty impactful to your business. The max coverage there, that is the number of applications that were tested against this, how many of them actually had an injection of problem associated with them. Then, the average coverage was 47. There were a lot of applications affected by this, is what that's telling us. Then, the total occurrence is 274,000 in change. Again, that's out of just over 500,000, so over half of the applications still had a problem with injection vulnerabilities. This is again, still a big deal, and then the total CVEs, 32,000 plus, CVEs associated with those CWEs that were mapped to injection problems. There are a lot of vulnerabilities associated with injection. It's still a big problem but those are the factors that OWASP looked at when categorizing and number 1 categorizing injection as a security risk but then also deciding where it falls on the list. In this specific list, it is number 3. Those are the factors that OWASP looked at. Here's the concept of injection. You have the client on one side, you have the web server on the other side, and the user supplies some input. Then an interpreter runs the commands, and then data is exposed, it's changed, it's supplied whatever it is. You can see, and I'm going to use my little mouse right here with my pointer on the screen. You can see down here this little screenshot of like a please log in. Well, this is a user-supplied input. Obviously, it's username or e-mail and then its password. Then you're going to click Sign in. You're going to click Forgot your password. This is an example and this happens all the time. This an example of a user-supplied input. If we go up here, the user is supplying some input that this webserver is going to take that user input and it's going to ultimately run some command using the input that the user-supplied and then based on the results of the command that it runs, it's going to expose data, or it's going to change something, or it's going to allow you to log in or whatever it is. That's the idea of user input data and then the application uses the data that the user-supplied in order to do something. Well, then that opens the door for an attacker to say, well, "Hey, I'm going to supply some crazy input and see if I can trick the back-end system to do some crazy stuff." Here is under the hood, if you will if you were to take a peek under the hood as it were to look at what's going on in a web application. Let's look at that same login page. I'm going to use my mouse pointer here again. The user supplies a username and they supply password and they click Sign in. Well, what happens behind the scenes is, let's say that this field, this username field is called text username. Then let's say that this field password is called the text password. That's the variable that is used in the code that builds all this. The value for the text username variable gets its value from this function called Get request string, username. This username that is supplied by the user is going to be input. Whatever is input here is going to be supplied right here and then that value is going to be stored in the variable called text username, same thing with passwords. They put in the password, get request during password, and then that value gets stored back here in the text password variable. Then those two things are then used in a SQL. This is the structured query language. Let's say that you have a variable called text SQL, and that equals this SQL statement. If you've ever used any database syntax or database programming, then you'll know that there is this structured query language. It has a specific syntax to it, and this is what it looks like. It's going to say select star, which means everything from users where the username equals, and then it's going to supply that variable text username. The password is text password. Effectively what's happening here is the user has supplied a username, the user has supplied a password, and ultimately those values have found their way into this SQL statement. Then as long as there is a username or there's users that have a username of that username, this whole SQL statement is going to then be sent to the back-end database. The database is going to search and it's going to say, I want everything you got. That's what that little star means. I want everything you got from anyone who has the username of whatever the user-supplied and has the password, make sure the password is correct as well. As long as those things check out, then I'm going to send you back all of the information I've got, which could be any number of things in terms of what the database is holding. It could be address, it could be like home address, email address it could be birthday, it could be name. It could be credit card number or it could be all kinds of different stuff. That's the idea that's going on here. You've got user-supplied input that ultimately turns into server-side Structured Query Language, in this case, SQL commands that are run against some back-end database. That's the overview of what is happening here. Let's say that we have, in this case, a web application, and the username that is supplied is John, and the password that is supplied is password. I would say don't use that password, it's a horrible password, it's easily guessed, but it does have a capital letter. It's upper or lowercase. It's got a zero in there, it's got special characters. But anyway, it's still horrible password. John and password. What's going to happen is those are input here in this login field, username and password you hit "Sign in". Then the back-end system is going to create a SQL syntax command that's going to interact with the database. The database is going to look it up and be like, "Yeah, there's a username John and there's a password like that, so that checks out." Then the server is going to be like, "You get your checked out. Now I'm going to give you the page that you're looking for. Let's go buy some skinny jeans or whatever, buy some organic coconut milk." Whatever you got. Anyway, so that's the idea that's going on here. What's happening again is going back to this example. Text username is username, text password is password. Then now with this SQL, command turns into is textSQL select star from users where username is John and password is password. As long as that checks out then we're good to go. As long as it does and it gives you that page and everybody is happy. Let's look at this again and say here's the way that you could supply an attack to this thing. Let's say that you supplied a username, that was John. But then you start to have these weird characters. You've got quotes and then you've got this word or, and you've got one equals one and then a single quote. Then maybe you don't even put in a password in this case. But you just put in that really weird-looking username. You're putting that in here and then you hit "Sign in", you hit "Submit." The question is, what happens? Well, if the web application is vulnerable then it will take that as the username and it will respond with the actual page itself. It's like, "Here you go. You signed in properly." Well, there's a couple of questions here. First, why are skinny jeans costing $238? But that's a totally different thing. But now the question is, is your server vulnerable will it supply the results given this crazy username? Is it vulnerable to an injection attack, in this case a SQL injection attack? Let's check it out. What's happened here, here's the weird username, there wasn't even a password at all. Again, here's this variable turns into this SQL statement. Now what happens is the SQL statement is select star from users where username equals, this is where things get weird. Well, username equals John, but you remember, I put the username as the attacker, I'll put the username at John and then double-quotes and then a space and then the word or, which is a special word in SQL syntax. Then I put one equals one single quote, and the reason for that is if you take this single quote and you come all the way back here to the beginning of the select statement. Select statement becomes effectively, this part right here ends up being not necessary or just worthless as it were, not looked at. But effectively what's happening here is as long as the username equals John or, and this is a logical OR so it's either this is true or this is true. As long as one of those is true, then as far as database is concerned, it returns a true response. As long as the response is true, then select everything from users where username is this or this, then it's going to return that data. In this case, it's saying, I want everything you got from users where either the username equals John or one equals one. Well, username John may or may not be there, frankly, it doesn't even matter in this case because there's an or statement here. As long as one equals one, which is always true, then because this is true or this is true, then this entire statement is always going to be true, which means this entire thing is true, which means that basically you're going to get everything dumped from the database, from the user's field. This is just going to respond with all your user data. In this specific case, it doesn't quite matter what the password is because the SQL statement doesn't even make it all the way to that point. It sees this it's like, oh yeah, that's true therefore, let's just respond true. That's the nature of how an attacker could take the SQL syntax and the idea that a user input value is supplied to a web application and take advantage of that and say, okay, well, then I'm going to supply you with some really weird looking usernames, except it's very crafty SQL syntax that I'm manipulating in order to trick the back-end database to spill a bunch of information. That's the nature of a SQL injection attack. Here I'll highlight this one more time. All of this right here becomes the true statement, just like I said, and then this part just doesn't even matter. That's the net effect and then it gives you all the data, which if you're an attacker, you love it, but if you're the application administrator or developer, then you do not like that. Another example, LDAP. Again, you hear SQL injection all the time, but that's not the only injection. In this case, LDAP it's the Lightweight Directory Access Protocol, is this protocol that's used for directory services. It's communication language applications to use this to communicate with other directory services. Directory services are going to do things like store your user ID, your password, computer accounts, that thing, that information shares information with other entities on your network. LDAP is a pretty common protocol, it's a pretty common implementation in the world today. The syntax of LDAP is different than SQL than the structured query language, but the idea behind an injection attack using LDAP is very similar to SQL. The net effect is an attacker is going to say, okay, I'm going to supply the LDAP search or filter engine as it were, with some really strange syntax. But it's going to be meaningful to the LDAP directory service, the LDAP protocol. Whenever I supply this, then I'm going to effectively trick LDAP to spill a bunch of information that I'm looking for right. Here, I'm going to use my pointer again. Here the example syntax in LDAP, maybe something like find and then, whereas in SQL, you would have this & statement in-between two different items, two different variables, that thing. In LDAP, you put it in front and then you put the two variables after this logical. Effectively what this is saying is we're going to add these two things together. As long as this and this are true, then we're going to find that stuff in our directory services or whatever. Here's an example. If you go to example.com/ldapsearch?user=John, and then the search filter, maybe this cn like common name equals plus user, and so whatever's here is going to get input into this, and so it's going to do a search on a filter where any name or username equals John in this case. That's an example syntax of what LDAP is trying to do. LDAP injection. Let's look at this really quick. If we have up here example.com/ldapsearch, and then user equals star, this means that we're trying to do a search for username anything, so for all users. What that becomes is search filter cn like common name, username effectively equals star. Then let's say that the web application uses a filter to match this user and password pair. Here's what that could turn into search login equals, here's that, and so it's going to & logically and together the user ID and the user password. The user ID is gonna be this user field, which again is right up here. Then the user password is this. Here's a bunch of crazy stuff which by the way, little Easter Egg here, little craziness. If you remember, in the last video we talked about cryptographic failures. You may have remembered me talking about MD5 and that's not good. That is a vulnerable cryptographic algorithm. It's not good, it's very weak. You would not want to use that here. But let's just say, for example, this is a vulnerable web application, because it's vulnerable to injection attacks. Frankly, it's vulnerable to cryptographic failures as well. This thing is vulnerable to all kinds of stuff. But nonetheless, let's just say again, for the sake of this argument, here's the logical and statement, the user ID is whatever the user supplied, and then the password is whatever the user supplied as well. That's what this application is going to use to filter to look for this LDAP user password pair. Suppose that the attacker submits this as the username, so everything from that star all the way over to this star. You might look at that and you may think, what in the world, I don't even know what that is, why would you do all that stuff? The answer is if you start to plug this in to this as the user, then it's going to result in some crazy LDAP search syntax. But it's going to be meaningful to LDAP and then we said password for the password. Here's what it's going to turn into. Search login, remember that and right here, user ID equals star, user ID equals star and so because you put all of this in for the user ID, then as the attacker maybe you knew in advance that, hey, we're doing an LDAP, look up and it's going to do this logical and statement and this is the way that LDAP looks for things. You're going to say user ID equals and then from this star all the way over to this star, that is the username. But what ends up happening here is that this logical and is just going to and these two things together. It's going to say, user ID star and we have to end it together with something. If it's that ended with itself, then what's that going to do? It's going to return a true statement. Then because you put this little pipe in there, that's a logical or statement syntax in an LDAP, so that's a logical or. What that does is it builds on out this LDAP syntax command and it puts a logical or between the user ID star and then the user password. Effectively what this is saying is either the user ID is star or the user password is a whole bunch of crazy, whatever. Like with the sequel injection example, it doesn't quite matter what the password is because you have forced it to say, hey, as long as this right here is true, as long as the user ID is that and user ID is that, which that's true, that and that is true, or the user ID is this and then that together with user ID is star or your user password is all that stuff, then frankly, it just becomes a true statement. Effectively what's happened here is that as an attacker, you submit this crazy username and frankly put whatever password you want because of the nature of the LDAP syntax down here. You have tricked the LDAP search filter engine into spilling all of the information that it would be looking up in this case. That's an example of an LDAP injection attack. That's something that could be vulnerable as well. It's important to know, hey, what's injection and what all would be vulnerable in terms of injection attacks. As we go through this and we say, are you vulnerable? Then here are some things you can ask yourself. Search the source code for any calls to external resources. You can see there system or executables or forks or there's different queries, that kind of thing. Anything that's making a request to an external interpreter, you need to be aware of that. It doesn't mean that you can't do that. It just means that you need to be aware and you need to put the proper security protections in place. Many languages have multiple ways to run external commands. This is a problem for you as the application developer because you may say, well, hey, maybe I've got a MySQL database that I'm running that's connected to my web application and that's part of my web application. Or I've got whatever. Then you may say, well, hey, I'm going to protect it from the normal syntax, from the normal command of executable that a normal user would run against that database. But then you've got to keep in mind, well, hey, there may be two or three or four or 10 other ways to extract data in some weird syntactical way. If you have not provided protection for those as well, then you've opened the door then for an attacker to come in and take advantage of your web application and run injection attacks against it. Because frankly, as an attacker, the attacker doesn't care if they run what would be a normal syntax command against a database, let's say, or against an LDAP server, whatever. If they have to run some weird exotic command, that's no one's ever heard of or not many people know about, whatever, they don't care as long as it works. The whole point of this thing is be aware that there could be more than one way to run these external commands and so you just need to provide protection for all of those. Review your code, search for places where input could get into the calls that go back to these back-end databases or to these LDAP servers or that kind of thing. You need to be aware when the user supplies an input to your web application and then you take that user input and you run commands based on that, then that's not good. You need to be aware of that. An application is vulnerable when this user supplied data is not validated or filtered or sanitized. You need to validate that stuff. That may turn into, hey, I need to not allow certain characters, like question marks or quotes or hashtags or whatever it is. You can see there the dynamic queries or non-parameterized calls without context-aware escaping. If those are used in the interpreter, so you need to escape those wherever you possibly can, but if you don't do that, then you're vulnerable to attack. You can see there, hostile data is used within the object-relational mapping, the ORM search parameters, to extract even more data or sensitive records. That's not good, obviously using the hostile data. Then that last one, hostile data is directly used or concatenated. Command contains both structure and hostile data dynamic queries, all that stuff. If you're using that, then your application is vulnerable to attack and so you need to be aware of that, you need to provide protection against that. How do you provide protection? Well, I'm glad you asked. Here we go. Let's talk about a couple of things. Protect yourself. Avoid accessing external interpreters whenever that's possible. It may not be possible all the time and I get that. But if you can possibly avoid it, then avoid that. That'll help out just right there. You can see there, use a safe API, which serves protections you need to put around APIs as well. But then that would possibly avoid the interpreter entirely, so look at that. Validate data to make sure it doesn't contain malicious content, of course. Structure requests in the ways that the supplied parameters are treated as data rather than potentially executable content. Again, the parameters that are user-supplied, make sure you don't execute against those. The application should only run with privileges that it needs to perform its function. This may be where you are allowing applications to run at elevated privileges and that's the problem. Maybe you've done all the protections you need, except now the application itself is running higher levels of privileges than it needs to and so that ends up being the issue. That's another thing. Any residual dynamic queries, escape these special characters. There's specific syntax that you can use for escaping characters. Then use a limit and other SQL controls within queries to prevent mass disclosures of records. What you can do there to limit is another special SQL word or command that can be used within a SQL command and it effectively limits the amount of data that can be exposed or spilled. That's one way to just control the damage, if you will. Then these are some resources that you can take a look at. I would point out, I've done this on the last couple of videos. That second one there, the ASVS, application security verification standard, that's the actual standard you can use to running into your application to make sure that you are in compliance or protecting against injection attacks. But that top, when there's proactive controls that you can put in place or there's different cheat sheets there with injection prevention and all of that. These are some good resources that you can take a look at from the OWASP organization that will help you protect your application against Injection attacks. But like we said, Injection is still a big deal. It's Number 3 on the list this year. While it's not number one, it's still high up there, so it's still a big problem and has been for goodness for many years, I mean pushing 20 years now, almost. It's been either number 1 or certainly in the top three or five for many years. It's a big deal. It's good to know about injection, what it is, how it works, and then how you can protect yourself. With that well, actually let me tell you this fun story. This is a crazy little extra fun here. This was taken from Brian Barrett wrote this in Security Magazine. This has been a few years ago, but it's still a fun little story. There's a guy named Joseph Tartara. I hope I'm pronouncing that right. Joseph Tartara. He was a developer out in California. He thought that he would have some fun with his license plate. You get these vanity license plates where you can put whatever you want on there. He decided as a developer, he would have some fun, he looked at the database online to see like, what are the license plate, available names that are not used or whatever. A bunch of them that he wanted were already used. But he found this one, the word null, N_U_L_L_ was available. He got it, he bought it and he said, all right up, that's going to be my license plates. It was cool. That's null just means empty or nothing. That's the idea of null when you're talking about computer programming that whole world. Anyway, he thought that'd be a fun little computer developer type, fun license plate. Well here's what happened. He's got the null license plate. Well then the police would be in and around California in a variety of cities, California is huge state, right? They would be around these different cities and in some cases, they would be writing a ticket, let's say they were writing a parking ticket, whatever. In some cases, these cars would not have a license plate and maybe that was part of the citation that the police were getting the car for whatever, let's say that the car did not have a license plate. Well, as a default, if the police officer did not write down the actual license plate number in the system that generated the citation this ticket, then it would default to null because there was no value there for the system because the officer did not supply anything. It's just an empty field, so it literally would put null in there. Well, Joseph Tartara's license plate is the value null. What ends up happening is every single one of these tickets that had a null entry for the license plate value ended up getting sent to Joseph Tartara and the state was like, hey, you have to pay all of these tickets. Of course Tartara was like, that was not me. Here's my alibi. That first of all, it's not my car. It's not registered to me. I was not in, I don't know, I'll pick Sacramento. I'm making this up, but let's say he lived in LA and the ticket was issued in Sacramento and it was the exact same day and time that he was in LA and he's got an alibi and have receipt and whatever you can prove. But it took forever for the states and Joseph to come to agreements on the fact that he was not liable for all of those tickets. Anyway, so while that's not necessarily an injection attack per se, it's still a bit of an injection story that I thought was fun. The null value gets injected into the police ticketing system. Then here's this guy on the hook for all these tickets that he has to fight. It took forever and all time and resources and whatever. It's just a big headache. Lesson learned, I guess therefore, Joseph and for the rest of us is that I guess, choose your vanity license plate carefully. Anyway, I hope you enjoyed that story, it's a fun little example coming on the heels of this injection discussion. With that, let me say thanks for hanging in there and listening to this video. I look forward to seeing you in the next video.
