About this Episode:
Are you familiar with the OWASP Top 10 Web Application Security Risks? This is the first monthly episode where security expert Prasad Salvi will join us to break down each risk one by one. Today we’ll discuss the first security risk listed—injection flaws. Discover what an injection flaw is, the different ways this attack can occur, and how to prevent it. Listen up, and join us next month as we cover the next security risk, broken authentication.
TestGuild Security Testing Exclusive Sponsor
Micro Focus Fortify is the recognized market leader in application security and is the most comprehensive and scalable application security solution that works with your current development tools and processes. Try it today
About Prasad Salvi
Prasad is an Application Security Consultant, a certified ethical hacker and CISA certified professional with a primary focus on providing services across the Secure Development Life cycle, Application Security and Penetration Testing spectrum. He is a part-time bug bounty hunter. He is a blue team expert delivering security training courses to developers and testers to make them proficient in application security and develop secure products. He has worked with major financial institutions and vouched to create a culture of security.
Connect with Prasad Salvi
- Twitter: prasad
- LinkedIn: prasad-salvi
- *** Check out all of Prasad's awesome course in Pluralsight **
Full Transcript Prasad Salvi
Joe [00:02:25] Hey Prasad. Welcome back to the Guild!
Prasad [00:02:29] Thank you, Joe, it's good to be back.
Joe [00:02:31] Great to have you. So I think this is gonna be awesome. Thank you for your help to him come up with this initiative to do the top ten of OWASP and we're gonna cover it once every month. So I'm really excited to dive into the very first one. So I think the first one has been on the OWASP list for a while and I used the think that…maybe I'm wrong. I thought it was listed as a SQL injection. Now it just lists injection. So I guess before we go into it, what is SQL injection?
Prasad [00:02:58] All right. So as you rightly said, it has been on the topmost spot for almost a decade now, if not less than that. So the (unintelligible) injection under it we have OS command injection, SQL injection, but the most popular are widely exploited vulnerability happens to be SQL injection. Now, as the name suggests, SQL, it has to do something with the database. So in this particular attack, SQL injection, we insert certain malicious SQL queries. Why are the inputs? Let's say there's a username and password field and instead of entering my own username and password, I try to manipulate that because when I click on the submit button, there would be some query which is being fired. For example, select star from users where a user name is Prasad and password is password, for example. But what if I change that query to the input. Now once I am able to do that, I can have a lot of impact on the application, which can result in really inserting or updating or deleting certain values in the database, shutting down the database, or executed some administrative tasks on it. So basically manipulating the queries that are running in the database to the inputs or untrusted input, as we call it, in the infosec world, happens to be SQL injection.
Joe [00:04:21] Very cool. So I actually did a quick search for news. I went to Google News, typed in SQL injection, and bam right on top. This was over the past two years. There's been an increase and high volume of attacks in the gaming industry. And I guess what they say is people are trying to do credentials stuffing attacks, trying to gain access to a gamer's online accounts by using a list of usernames and password combinations. I think it's a substantial majority of those were SQL injection attacks. Is there any reason for that or is that just a common way? Because obviously things are stored in the database. So the best attack to try first is SQL injection.
Prasad [00:05:01] Of course. I mean, there are two sides of the coin. Now, if you say that, why we go for the gaming industry. First of all, they don't have any regulations as such. Like, if we talk about banking and finance, they have certain regulations, for example, PCI wherein we have to make sure that those applications are secure. We have to follow the process. Let's say we use MicroFocus Fortify on Demand to scan that application's code. But in the case of gaming, they probably don't have much security in mind. Their end goal or the end game is that the users or the end-users play the games have that convenient part so that they don't put much security controls in there. And once I'm able to download your entire database through SQL injection, that's like the win-win situation for an attacker wherein he gets access to the entire database, then he can post it on certain websites. Let's say (website's name) is one of the famous websites where all the hackers post their data into, whichever they have found. And then I can just go to (website's name) and I can say alright xyzgaming.com data has been breached and these are the username and password combinations. So credentials stuffing basically means that you pick a username and password which has been breached and try it on a different application. There is a possibility that the same person who is using the gaming site might use a similar password or the same password for other places like social media or banking. That's why we always say that you shouldn't be having the same password everywhere. You should use different passwords that are strong and again, coming back to SQL and the database. It also depends on how you're storing your passwords like you cannot store your passwords in clear text in the database. If you do, then there's a major problem, because if your application is vulnerable to SQL injection, then you're exposed directly. So the hacker doesn't have to do anything. And if he gets all the clear text data. Also depends upon how you're storing it.
Joe [00:06:52] So interesting. That's a good point. I guess if it's regulated or not, maybe if someone is developing a game they don't even think about why would someone trying to hack my game. It could be like you said just because it's storing (??) all the data and the database maybe it's clear text. Are there any other ways people can create it so it prevents these types of attacks as a developing code?
Prasad [00:07:11] SQL injection of course. So let's say, like the example I gave you if there's a username and password field. Now, there are two types of queries. There is a dynamic query and there is a static query. So let's talk about the dynamic query. Let's say I just enter my username and password. And whatever I enter at that moment, a real-time query is rated at the runtime and it's being fired in the database or the database interpreter. Now, let's say if I enter a single code because now everyone knows that an SQL query ends with a single code. Now, whenever a query reaches the database interpreter, the interpreter says, all right, where is the last single code? Where do I have to end the query? Now, if, let's say I enter, Prasad and single code and the user name itself and if it is a dynamic query which is being generated. Now, the query becomes select star from users. Their username is within single codes, Prasad and single code and password, or whatever I enter. Now, when this query will reach the back end of our database interpreter, the interpreter will try to find where do I need to end the query. Where is a single code? Because I have already given a single code in my username box, the database interpreter might think that we can trick it to believe that this is where the query ends. Now if it is a dynamic query and the errors aren't really handled well, the database will throw back a stack trace like all the errors on the screen, which would include the database errors, the line number, might be the code or the query as well. That's why we say error handling should be good as well. But in that case, even if I get a database error, let's say it's an Oracle database at the back end. I see something called ORA, which is an Oracle error. So an attacker would know just with a single code that the database that you've been using for your usernames and passwords and all sensitive data is an Oracle database. So I can go ahead and try to manipulate the input so that I can get into the database. Now, this happens in the case of dynamic queries where you just take anything that the user is giving you. You put into a query and you fire it. Now there's a static query. This is the recommendation for SQL injection and the best practice. There is also called as a parameterized query. Now, for example, let's stick to the same username and password page. Now, in this case, instead of creating a query at the real-time or runtime, I will already create a query with say select star from users where user name equals to add rate name and password equal to add rate password. Now and then I assign the values that the user is entering to add rate name and add rate password. Now add rate name and add rate password are just the place holders. I've already defined the query in my code. Every time anyone enters a user and password this query needs to be fired. Now, what is the add rate name and add rate password? It will have the details of the user or whatever the inputs that the user has provided in those X boxes. We just take those and take those values and assign them to like the name-value pair. Add rate name, that would be my name and the value would be, let's say Prasad single code. So there's no dynamic query generated. We already have a query and every time that static query will run, the moment you hit the submit or the log in button the static query would fire. So, in the same example, if you hit the log in button, the static query would be fired and then the database will check all right. add rate name let's say is Prasad single code. Now, do I have Prasad single code in my database? It wouldn't find anything. And then it will throw back an error saying that invalid username and password. So this has been the best recommendation for SQL injection since it has been found, for a decade. Now, if you go for a (unintelligible), you have something called as parameters or add function. So whenever you define, let's say, whenever you define a static query, you can use the parameters of the add function and add those name-value pairs. Like for example, add rate name, comma, input.getvalue (??), whatever the users enter or use in inbox. If you go for Java then you can use something called a prepaid statement, which is the equivalent of parameter queries, a similar thing, but just a different syntax. But it works exactly the same way. And like there's a good website, call as bobby-tables.com. It has all the mitigations for SQL injection, for all possible programming languages. Like if you're using Golang or Ruby or Python, you can just go to bobby-tables.com, and you'll find a good secure code snippet for SQL injection. So you can use that as is in your code.
Joe [00:12:17] So I think this would be the core features of an application, logging in, and things like that. So are people just ignorant about these attacks still or oversight or like what…how do they still not do this? I guess these best practices?
Prasad [00:12:32] Yeah, that's a great question, Joe. So what happens is now people know about security. Like if I'm a developer, I know what that to my username and password feel should have all the security controls. Or if there's a transaction page, I should have all the security controls. But have they fail to understand that once the user logs in everything that they see on the screen has to be secure in the same way that you have a security transaction page or a login page? Now, let's say I open my application, I log in and I see five different tabs out of which three are very critical, like transactions, credit card statements, or anything else. But the remaining two are just you're giving me some reports. Or, I'm searching for something like when was the last time I paid a hundred dollars of pay? So I just like to end from like generative report of the dates from, let's say, September to October. And I'll try to see what are the different transactions I've made. So there might be a health breach or a search box for you to sort something. So in these cases, unfortunately, the development community does not focus because as for them, this is something that we have given, again, the convenience part that we spoke about, the gaming world. Now, this is the convenience that we have given to our users to search for anything that they want. And that query would be fired in our database. Now, that's why they probably become a bit lenient when coding for these pages while they put all the controls and all possible security things in the remaining pages. But again, once you log in, you should secure everything that you see on the page.
Joe [00:14:13] Well, that's a good point. So they may have an oversight like a page that gives them full search abilities. And I even think about…they could still get attacked that way, I guess.
Prasad [00:14:24] Yeah, absolutely. So even if my search box after I logged in is vulnerable to SQL injection, my entire application is vulnerable. So I cannot say that or I know it's in the search box, but my transaction page is safe. We cannot say that because it's after authentication. And if one thing is vulnerable, your entire application is problematic.
Joe [00:14:45] All right. Good to know. So like I said, it's not just sequel injection. They list a few other ones like it's just injection sequel being one of them. Probably the most common. I like to cover the three other ones. So the other one is no sequel. What's a no sequel attack? How is it different from a sequel attack?
Prasad [00:15:02] Yeah. Thanks, Jill, for asking about the new sequel injection. Now, these No sequel injection allows the attackers to inject life in code or commands for the database that don't use SQL queries like, for example, you have a MongoDB that does not use any SQL query. So in that case, if you're able to manipulate the code or you enter particular scripts where you can fetch the details from the MongoDB. It is called as no sequel so anything which is not using a sequel is a no sequel injection. Similar thing, but you do it through a code or a script rather than manipulating a query for the single code.
Joe [00:15:42] I guess the reason why this has become more popular is companies like Facebook and Amazon use things like Mongo, I think DB, and it's not relational. Is that what it is? So it's like (unintelligible) relational database?
Prasad [00:15:54] Yeah. So MongoDB uses the binary JSON, like you call it, BSON data format and it comes with a secure base in query assembly tool. Now, queries can also be represented as be it based on objects or binary data which we got. So the direct string injection is not possible in that case. However, a MongoDB deliberately can allow applications that might run Java scripts on the server. There where you have directives like dollar there and mass-produce operations on MongoDB. Now that's when you can get into trouble.
Joe [00:16:30] So rather than a sequel like valid like select star from password or something you could do actual JavaScript injection it sounds like.
Prasad [00:16:38] Well, JavaScript. Yeah, but that's only for MongoDB and that's why it's called no sequel injection.
Joe [00:16:43] Got you. So anyway to stop these types of attacks or try to harden your system against these types of attacks?
Prasad [00:16:51] That's again, a great question. So you can I believe in case of no sequel your input validations and secure coding, it comes to your rescue. Like if you're not using or not performing secure coding in your applications, like the untrusted data that we spoke about at the beginning. Anything that the user is entering, you're accepting…your application is accepting the user input that needs to be validated and there should be controls both at the client-side and the server's side. Like, for example, if I'm using a Mongo DBE and let's say it expects some JavaScript coming in, I would know what that JavaScript would be like. For example, if I need to load some report on the page so it would have some proper syntax. I can whitelist those particular syntaxes or the script text. If someone says script a load exercise or document a cookie, this means it has come in an input feed. This means that someone is trying to perform either a cross-scripting attack or trying to perform no sequel injection attack because it might have a code related to the database. Like I said, maybe using the dollar where (??) tag in MongoDB. So it's always good to perform secure coding, have adequate validations both at the client and server-side, and also the white list of the allowed characters.
Joe [00:18:12] Cool. So the other type of injection is OS and I'm not sure if I've heard of this one. Is that actually someone doing an operating system command that's able to inject it into an interpreter to fool it, to think that it's the actual operating system that's doing it? What does…I guess what is an OS injection?
Prasad [00:18:28] So OS, it's called OS command injection so the goal of an attacker in this particular attack is to execute different voice commands or like operating system commands. Now command injection attacks are possible. Then let's say an application passes unsafe user-supplied data like in the HTTP, the forms of cookies. Let's say I this again, the u…let's take a different example. Now there's a page value or accepting some values. Let's say you're generating a report. I give you the dates that I want my data from the 4th of October to 30th to October, for example. Now the server will get certain requests once you click on Submit. Now, what if I am able to manipulate or perform a man in the middle attack and change that particular request to include some OS command, let's say open up calculated or PXE on the server. Or open up command prompt on the server. Now, if there is, again, no proper validation on the server-side, the server will trust that input coming from the user and then try to execute those commands at the OS level. Maybe you will gain access to the command prompt. There's something called a reverse shell wherein a… or the shell access where you sitting at your home or your lab, you can get access to someone else's or the victim's command prompt through OS command injection. So usually, OS command injection now is common when you use Excel sheets which are uploaded to an application so file upload is also very important to be checked. What sort of files are you uploading? Is there any content filtering? What are the things that are included in an Excel file? Because if I'm expecting an Excel file which has my name and let's say date of birth, why would someone have a macro written inside the Excel? So it's important to check that as well. Through macros, we can run and cue OS-related commands on the server as well.
Joe [00:20:29] So is that a common attack? Like I say, I haven't heard of this one before, so I don't know.
Prasad [00:20:33] Not very common. As I said, I mean, you don't find this unless the application is like a way too vulnerable or intentionally vulnerable like we had automation (??). But that's why SQL injection tops the list. But again, OS or LDAP injections are not that widely exploited, but they are still attacks, which need to be dealt with so that they are categorized under injection attack.
Joe [00:20:57] Absolutely. So that brings us to like they're not that common but there could still be very, very critical. And you mentioned LDAP, which is the last one that's listed here. I don't know if there are others. But I just did a search once again in Google News for LDAP. And last week, Apple paid I think over two hundred thousand to a white hat hacker who ran on the company network and find a bunch of vulnerabilities. And a majority of them had to do with the LDAP. I guess the attack to get access to the internal LDAP services, those stores the users account credentials. So I guess a little bit about what is the LDAP attack and how you can prevent that? How even Apple missed it I guess?
Prasad [00:21:35] Yeah, so LDAP is a lightweight directory access protocol, which usually is used in the active directory like in the major organizations where you have active directories, which stores usernames and passwords of all your employees. So LDAP protocol basically helps you or your users to log in and let's say to a single sign-on or within your environment or within a network. Now, again, to exploit this particular attack, it's not simple to exploit it. You have to be on the same network. You have to gain access to a particular device that is on that network so that you can be able to exploit LDAP injection. Like in the case of Apple, maybe the bug bounty hunter got access to one of their network devices or a device that has on the environment already. And so that he could exploit the LDAP injection. That happens within your active directory where you store your users, employees, or your usernames and passwords. So that attack takes advantage of the active directory and tries to manipulate or gain access or fetch the different users and passwords from the active directory.
Joe [00:22:44] Okay. Yeah, because it is said in the article that the person used brute force to get a valid username and then once it had a user name, was able to log into several of the user accounts until he found one that had core administrative privileges on the network. I guess that's how they get access then to LDAP.
Prasad [00:23:00] Exactly. So once you have admin access, I mean, not in the case of LDAP. But when you talk about compromising an application or hacking an application, it's always…the attackers always try to find out who the highest privilege user is, because once you have the highest privilege user, you can do anything. You can add your own users, you can delete stuff. So in this particular attack, they said the brute force. Now, this means that Apple didn't have adequate control to check if, you know, they didn't have adequate monitoring or logging maybe they or didn't have an account local. There was something missing or they didn't have to capture, for example. And this way, the brute force was successful and the attacker was able to find the admin, a user's username. And then through that, he could get into the LDAP server.
Joe [00:23:48] Cool. Prasad before we go is there one piece of actionable advice you can give to someone besides all the actionable advice you gave them already. How they can help stop injection attacks? And what's the best way to find or contact you?
Prasad [00:23:59] All right. So as I've mentioned earlier like I like to read it myself, that everything that you could try to perform secure recording, I don't miss out on a single input field. Every input field of application should be treated as secure as any other pages or any secure application would have. Now, if they want to reach out to me, they can follow me on Twitter. They can reach out to me on LinkedIn now until they can reach out to me at Pluralsight. If they have access to it, then I would be happy to help.
Rate and Review TestGuild Security Podcast
Thanks again for listening to the show. If it has helped you in any way, shape or form, please share it using the social media buttons you see on the page. Additionally, reviews for the podcast on iTunes are extremely helpful and greatly appreciated! They do matter in the rankings of the show and I read each and every one of them.
