CompTIA CYSA+ CS0-002 – Mitigate Web Application Vulnerabilities and Attacks part 2

3. SQL Injection (OBJ 1.7)

SQL injection. In this lesson, we are going to talk about SQL injection. But before we do that, we have to talk a little bit about what SQL is. Now, when you deal with a database, you have to have a way to talk to that database. And the way you get information or write information or update information from that database is by using SQL statements. SQL is the structured query language and it’s used to select, insert, delete, or update data within a database. Those are four key terms because those are the four keywords that are used with SQL and they’re going to tell the system, this is what I want to do. I want to select something. It means I want to read from the database, I want to insert something. It means I want to put it into the database, I want to delete something.

That means I want to delete it out of my database and remove it. Or I want to update something, which means I want to give it the latest version and replace what’s already in the database. So these are the four keywords you’re going to see a lot. Now, how does SQL normally work when you make a request? Well, let’s say I wanted to log into a website. I have a form it has for my username and my password. And so I’m going to type in Jason as my username and pass one, two, three is my password. And then I click the log in button, it sends that information over to the database and it makes a query. And so what it’s going to do is find out is the password. I sent the same password that’s stored in the database. Well, it does this using an SQL statement.

It’s going to say select star from users, where user ID equals what I inputted Jason and password equals what I entered pass one two, three. So we take that information and we pull it from the database and we see, do we have a match? And if we do, that means we’re going to be allowed in and we get access granted everything’s wonderful. That’s the way basic SQL is going to work. Now, what we’re going to talk about though, is code injection. And this is how people can take advantage of SQL and insert things that don’t belong. When we talk about code injection, it is a form of an injection attack. This is the insertion of additional information or code through data input from a client to an application. When we talked about things like directory traversals, that’s a type of injection attack.

When we talk about cross site scripting, that’s a type of injection attack. And SQL injections are another form of injection attack. When I talk specifically about SQL injection attack, this is an attack that consists of the insertion or injection of an SQL query via input data from a client to a web application. And so I’m trying to insert something into that SQL so it can apply that code and do its logic on it and then give me some kind of a response. Now, as an attacker, the attacker has to try every single input there Is to include elements such as URL parameters, form fields, cookies, post Data, and Http headers to identify whether or not there’s an SQL injection vulnerability. That sounds like a Lot of work, but honestly, there’s a Lot of Great tools out there that will automate this process for an attacker.

So you want to make sure you’re protecting your databases by understanding SQL Injections and what you can do to prevent them. So how does an SQL injection actually work? Well, let’s go back to our example of logging into a website. Let’s say I have a form. Well, I’m going to go ahead and put in my name there Jason. Then I’m going to insert my password. But instead of entering Pass One, Two, three, since I Don’t know the person’s password, I’m just going to put in an Apostrophe or one equals One semicolon. Now that seems kind of Weird, right? But when I put that in and I go ahead and click the Login Button, what’s going to happen? I’m going to send in the command select Star from users where user ID equals jason and password equals apostrophe, apostrophe or one equals one semicolon apostrophe.

Now, notice that when I send that in, I’m going to get Access Granted. Why is that? Well, because I just performed an SQL injection. Essentially, what ends up happening when you have something like an Apostrophe, it’s an escape character. And so what I’m saying is, find the Password that matches Jason, or if One equals One. Well, let me ask you, does one equal one? Yes, it does. Today, Yesterday, Tomorrow, and every day in the future, one is always going to equal one. And so every time we run this command and we do Jason, and then we do that quote or one equals One, that’s going to return a positive result because it’s Boolean logic. Even if my Password, which in this case is blank, because I just have the quote Mark, doesn’t match my password in the database, well, guess what? The or one equals one will equal It, and therefore I’m going to be able to get Access granted.

This is why SQL injections work when people are trying to break into databases. So SQL injection can be prevented, though, and we have to think about how to do that as Cybersecurity analysts, the way we’re going to do this is by preventing them through Input Validation and using Lease privilege whenever we’re accessing a database. There’s a couple of other advanced techniques that we’re going to talk about as well as we go through this section. But for right now, remember, if you have SQL injection, you can prevent it doing Input Validation. Now, anytime on the Exam, you see Quote Mark or One equals one on the exam. What are you going to say that is? That’s right. That’s an SQL injection. We know that every single time.

Now, another big vulnerable area when we start talking about databases is the idea of insecure object reference. Now this is something that we have to think about because when we talk about insecure object reference, this is the coding vulnerability where unvalidated input is used to select a resource object like a file or a database. Now, let me give you an example of this. Let’s say I decided to start my own bank. It’s now called the bank of Dion. So we all go and sign up for my bank and we all get an account number. If you want to access your account, you go to Bankadillon comAccount PHP question mark account equals 1234. That’s my account. Now this is an insecure object reference. Why? Because I have this 1234 shown right there, which is my account number. So if I just change that and decide to go to 4321, maybe that goes into your bank account and now I’m able to access your records.

That’s what we’re talking about. We talk about an insecure object reference or a direct object reference. Both of these are a term for this type of situation. So how do we prevent this? Well, we’re going to implement access control techniques inside our applications to verify a user is actually authorized to access that specific object. So if I was logged in as Jason and I tried to access Tamra’s account and choose 4321, it should give me an error. But if I don’t have those type of protections in place, and I’m just saying, show me what’s in the database at this location, 4321, it would show me that location. And so that’s why insecure object reference is a bad thing to have. Now for the exam, if you see something with an apostrophe or a double apostrophe, guess what? It’s an SQL injection almost every single time.

This is a great thing to remember for the exam. It’ll help you answer some questions. Now I want you to remember, it doesn’t have to be just one equals one. Anything that’s a true statement would work. It could be seven equals 715 equals 15, eight equals eight. I don’t care as long as it’s something equals something. And both those some things are true. This is going to be a sign of somebody trying to do an SQL injection on you. I guarantee on the exam you are going to see SQL injections. You will probably have at least three to five questions that are going to be answered with the words SQL injection, either in the multiple choice or in the Pbqs. It’s just that much of an important topic. You’re going to see it, I promise you.

On the exam, you’re going to get log questions showing you SQL injections and you’re going to have to identify them as SQL injections based on what you see in the URL again, look for those Apostrophes. Look for the one equals one, the seven equals seven, things like that. If you’re asked how you can prevent an SQL injection, what is the answer? Input validation. If we validate the input, we can make sure that we say, oh, we see somebody putting in an Apostrophe. We’re not going to accept that. We’re going to throw that input away. We’re not going to send it to the database. These are the things you have to remember for the exam. I promise you, SQL injections are coming. So keep your eyes out for them and you’ll find them in the logs.

4. XML Vulnerabilities (OBJ 1.7)

XML vulnerabilities. In this lesson we’re going to talk about XML, which is the Extensible Markup Language. This is used by web applications for authentication and authorizations and for other types of data exchange and uploading. Now here you might hear some people talk about this as XML Vulnerabilities, XML Exploitation, or even XML Injection. Now technically, XML injection isn’t really accurate. It’s more of an XML a Parsing Vulnerability that people are exploiting. But on the exam you may see it called any of those three things. Now when we talk about XML data, the XML data itself has to be submitted from you to the server or from one server to another. And so when you’re dealing with XML data, you want to make sure that it’s submitted with encryption or input validation.

If you submit XML data without encryption or without input validation, it’s going to be vulnerable to spoofing, request, forgery and injection of arbitrary code. So we want to make sure we prevent that. Again, input validation is here to help and so is encryption. Now when you look at XML, it looks something like this. This is a basic XML that I set up just to show you the example of it. You’ll notice the first line here, it has XML listed right in there. What version of XML and what type of encoding we’re using? The second line, this is what we’re defining. We’re defining a question in this case. And then we have a couple of different fields inside this question type. For instance. I have the ID. In this case I’m identifying it as CYSA 2001.

It’s the first question in the second version of the CYSA Plus exam. Then I have a title. Is this an XML vulnerability? And then I have a choice yes and a second choice no. You can define these with any kind of terms you want. This is just how I define the structure for my question because maybe I have a quiz app and it’s going to read this information and display it to the screen. So you can get different questions while you’re practicing for your CYSA exam. And then you’ll see they all just like HTML, have the slash at the end of them closing out those brackets and closing out the XML. If you see something like this, I want you to recognize it as XML code. Now the next thing we’re going to talk about is some of the exploits that we can have with XML. Now the first one we’re going to talk about is an XML Bomb or a Billion Laughs Attack.

Now this is where they take XML and they use this encoding to encode those entities that I just showed you and expand them to exponential sizes, consuming memory on the host and potentially crashing it. So what does this sound like to you? Well, it sounds like a bomb or a denial of service attack. If I can go forward and I can start consuming all these resources on your web server. By uploading some kind of bad XML file, I can take you down. And that’s what we’re trying to do with an XML bomb. Now the next one we’re going to talk about is an XML external entity or XE. Now this is an attack that embeds a request for a local resource. This sounds kind of like a file inclusion, doesn’t it? Well, let’s take a look at what this looks like.

Well, if we have something like XML, it’s going to look like this. And we have XML, the version and the encoding type. Then we have the document type. We’re defining this as Foo, which is just code or speak for some junk variable. Then we have the element foo any, we have the entity XXe system and then we have that file, file, etcshadow. And then we end this out with some kind of data type in XML. In this case we’re calling it Foo instead of question or Title or ID. So what really are we looking for in here that’s really looking bad? Well, that Etsy shadow file, right? By looking at that file Etsy shadow, that tells me they’re trying to do a file inclusion. And because they’re doing it through XML, this is known as an XML external entity or XXe type of attack. Now, to prevent XML vulnerabilities from being exploited, what do you think you want to do? You want to use proper input validation? That’s right, input validation.

Input validation, input validation. We keep talking about it, but it’s really that important. Are we sensing a theme here? If we validate the input from a user, whether it’s a URL being inputted, a file being inputted, a field being entered on a website, we can prevent a lot of these security issues. So always remember, input validation anytime the user is giving you something and that will help prevent a lot of these different attacks. Now for the exam. If you see something with XML written in it and it is clearly XML, guess what? It’s going to be an XML vulnerability that’s being exploited. They might call this XML Vulnerability, they might call it XML Exploitation, they might call it XML Injection. Whatever they’re talking about, it’s still an XML vulnerability that’s being exploited here.

Now, if you see anything that looks like the code in the format that I showed you in this lesson, guess what? It’s probably XML. Now the only tricky part with this is that XML code can often look a lot like HTML code, or it might look like JavaScript. The big difference is that when you’re dealing with HTML or JavaScript, there are defined keywords for each of those bracketed entries. With XML, you can make those say anything you want depending on how you’re configuring your XML. So just take a second to read the code and identify. Does this look like HTML? Are they using something like font or image or ahref, that’s HTML if they’re using something like question or ID type or element or entity, that’s XML. And so this will help you figure out which one they’re referring to so you can get the right answer.