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

7. Session Hijacking (OBJ 1.7)

Session hijacking. In this lesson we are going to talk all about session hijacking. But before we do, we need to talk about session management because session management is a fundamental security component in our web applications these days. When we talk about session management, this enables web applications to uniquely identify a user across a number of different actions and requests while keeping the state of the data generated by that user and ensuring it’s assigned to that user. Now, when we do session management, for instance, you log into my website and there’s a lot of other students who are logged into my website. Right now. When you’re logged in, I need to know what lesson you’re watching, I need to know what quiz you’ve passed.

And all of that is session information while you’re connected to me. And then when you’re done with that session, I need to save that in my database. So that way when you log in next time, we didn’t lose your results. Now, a lot of the way that people do this though is, is not just in the database but they also use cookies. Delicious cookies. No, cookies aren’t that delicious. We’re talking about cookies in the cyber sense. And the reason we have to use cookies is because web or Http is a stateless protocol. This means that the server doesn’t preserve any information about the client by default. So if you want to store that information, you have to either store it in a cookie or in your database. Now cookies allow web applications to retain this information about the users of the website and normally these cookies are going to be stored on your client.

Now a cookie is essentially just a text file. It’s a text file that’s used to store information about a user when they visit the website. Now that cookie is created when the server first sends the Http response header with that cookie. Then any subsequent request headers that are sent by the client will also include the cookie. So we can send that information back and forth. Because of that, we want to make sure that that cookie is protected because it is being transmitted across the internet. Now, when we talk about session cookies like these, these are going to be non persistent. They reside in memory. And when you’re done and you close out that browser instance, guess what? That cookie would be deleted as well. But not all cookies are just session cookies. Some cookies are going to be more persistent.

And these are known as persistent cookies because they stay around for a while. These cookies are stored in the browser cache until they’re deleted by the user. When you do the clearing your cookies or when they pass a defined expiration date, for instance, you might connect to my website and my cookie might say this cookie is good for seven days. And so if you came back in eight days, that cookie would be gone and you’d be like a new user to us if we were configured that way. That’s the way cookies work. Now, when we talk about cookies again, they have to be protected. And so when you’re sending these cookies or you’re storing any kind of confidential information in them, you should make sure they are encrypted. By encrypting those cookies, you can keep that information confidential because remember, confidentiality and encryption go hand in hand.

Now, the next thing we need to talk about is session Hijacking. As I said, a lot of these cookies are session cookies. And so Session Hijacking relates to this really well. When we talk about session Hijacking, it’s a type of spoofing attack where the attacker disconnects a host and then replaces it with his or her own machine, spoofing the original host IP address or using some other mechanism. For instance, a lot of Session Hijacking attacks occur through the theft or the modification of cookies. So if I can steal your cookie, I can take over your session and pretend I’m you. Now, another way that this can be done is by doing session prediction. If you remember from your Security Plus or Network Plus days, every time you make a connection, there is a session number that’s associated with that by the Http protocol.

And if I can guess what that number is, I can jump in and take over. Session prediction attacks are simply a type of spoofing attack where the attacker attempts to predict the session token to hijack that session. Now, the session token has to be generated using a non predictable algorithm and it must not reveal any information about the session client. Essentially, it’s a one time use ticket for the duration of that session. And so it might be some long random number, but how it’s generated has to be non predictable. If it is predictable, somebody can guess it and they can take over your session. Now, the next thing we need to talk about here is cross Site request Forgery, which is XSRF or CSRF. It’s written both ways.

As an abbreviation, I tend to prefer CSRF, and you’ll see me use that throughout the course. Now, Cross Site Request Forgery is a malicious script that’s being hosted on the attacker site that can then exploit a session started on another site within the same browser. Now, as an attacker, if I want to conduct a cross Site request Forgery, I need to convince the victim to start a session with the Target website. Now the attacker can then pass the Http request to the victim’s browser and spoof this as an action on the Target site, such as changing a password or an email address or something else like that. Now this request could be disguised in a lot of different ways. They can use things like image tags and other HTML coding. And this could also be accomplished without the victim necessarily even having to click a link.

If they do it successfully. Now, if the target site is going to assume the browser is authenticated, this is because they have a valid session token from that browser already from that victim. It doesn’t have to have any additional authorization for the attacker to do what it wants to do. So think of it this way. You have two tabs in your browser. One is the attacker’s website and one is your bank. You’ve already authenticated to your bank, but now you’re connected to the attacker’s website. Another tab, they can use Cross Site request forgery to try to manipulate and be able to go and do things on your bank account as you because you’re already in that state. And that’s really what this Cross site request forgery is going to do for them.

Now, how can you prevent Cross site request forgery as a defender? Let’s say you are working for the bank and you want to make sure that nobody is going to perform this against your customers. What do you do? Well, you can use user specific tokens in all the form submissions to prevent cross Site request forgery. And this is something your web developers would be able to do as part of their secure coding practice. So the last thing I want to talk about here is cookie poisoning. I know we’ve talked a lot about cookies and it’s making me hungry, but let’s talk about cookie poisoning and then we’ll finish up this lesson when we talk about cookie poisoning.

This modifies the contents of a cookie after it’s been generated and sent by the web service to the client’s browser so that that newly modified cookie can then be used to exploit vulnerabilities in a web application. If you want to be able to counter cookie poisoning on your systems, you want to make sure you validate the input of your web app to account for any tampered with cookies. By doing encryption of your cookies during transmission and storage, you can help prevent this. And if you delete cookies from the browser cache when the client terminates their session, it doesn’t leave those cookies sitting there being able to be poisoned by somebody else.

So this is all about good cookie management. Now, I know a lot of people are against cookies in websites and a lot of people turn off cookies, but a lot of sites need these cookies to operate. And so you have to be able to think about this if you’re the guy or a gal who’s programming these websites, do you have to use cookies to do this? Can you do this as saving things in your own database? Can you do this another way? And if you can’t, and you have to use cookies, make sure you’re doing it securely by making sure they’re very time limited, they’re deleted when you’re done, and they’re encrypted anytime you’re storing data in them.

8. Sensitive Data Exposure (OBJ 1.7)

Sensitive data exposure. In this lesson, we’re going to talk about sensitive data exposure, which is when a software vulnerability occurs that allows the attacker to be able to circumvent access controls and retrieve confidential or sensitive data from a file system or a database. Essentially, we’re having a breach of confidentiality here, so we want to make sure we don’t have this happen. So how can we end up preventing sensitive data exposure? Well, we should program our web applications to only send data between authenticated hosts using cryptography and encryption to protect the session. Now, when it comes to encryption, what type should you use? Should you use your own encryption mechanism? Should you make something up because you’re just that smart? No, you should use what everybody else is using.

You should be using AES. You should be using other things that are widely known and widely tested because those have been proven to be secure. As smart as you may think you are, using your own encryption scheme is a recipe for disaster because our own encryption schemes aren’t tested to the level that AES and other worldwide standards are. So we should really be using those worldwide standards as a best practice whenever we’re using encryption. Now, another thing you need to avoid inside of your applications is the use of hard coded credentials. This means you don’t want to be able to put in things like your database credentials inside your web app or your usernames or your passwords or things like that.

If you’re typing them in plain text and hard coding them in even as a hash, that is something that could be taken and exploited against you. And this would be another thing that leads to sensitive data exposure. Another thing we always want to make sure we do is disable the use of client password, autocomplete features, temporary files and cookies whenever possible. By doing this, we can reduce the risk of sensitive data exposure. Now, speaking of cookies, one more time, let’s talk about cookies. There are five key areas inside of your cookies that you need to think about because these five areas and these five attributes are things that may offer client protection depending on how you set them up.

First, we have secure when we talk about the secure attribute, this instructs the client’s web browser to only send the cookie if it’s being sent over a secure channel like Https. Basically, it requires encryption for you to be able to pass the cookie. Second, Http only. This prevents attacks such as cross site scripting because it disables access from client site scripting to your cookie. The only way you can access the cookie is over Http third domain. This is going to set the domain of the server that the cookie is valid for. Cookies are only going to be able to be accessed from the domain or subdomains specified within this particular attribute. So it really limits who can access that cookie.

Fourth, path this is going to specify the URL path for which the cookie is valid. Now, this may be the domain, but it also might be a subpart of the domain. For instance, you might have a cookie for deontrain. com, or it might be set to the path of deontrain. com accountcoorscyysa or something like that. Then fifth expires. This is used to set persistent cookies that will expire at a certain date within this attribute. So I might set my cookie to expire after seven days, 30 days, 60 days a year, whatever it is. Just remember, the longer that you keep this, the more chance there is that data inside that cookie could be accessed.

9. Clickjacking (OBJ 1.7)

Clickjacking. In this lesson we’re going to talk about the dangers of clickjacking. Clickjacking is a type of hijacking account that forces a user to unintentionally click a link that’s embedded in or hidden by other web page elements. For instance, let’s say I was playing a video game and there’s a big play button and I don’t see that. Behind that there’s actually a Pay button. And if I click that link for play, I’m not actually clicking the play button. I’m clicking this hidden layer that says Pay and that’s going to charge me. This is the idea of using clickjacking. Clickjacking is used when a victim clicks the link. They can be redirected to what appears to be a legitimate page as well. For instance, I click on something, it takes me something that looks like a login page.

I enter my username and password and lo and behold, I didn’t really log into my site, I just gave them my username and password. This is another form of clickjacking, another reason you have to be on the lookout for it. Now, clickjacking is made possible because of the use of iframes within HTML. Essentially because of these iframes that are allowed within HTML, you can actually have invisible iframes that’s accepting the values when you’re inputting your credentials even though you don’t see it on the screen. It’s really really tricky. But it is something that can be done through clickjacking. Now, one way to prevent clickjacking is by using frame busting. Now frame busting is a technique that removes the malicious iframe loaded on the site by forcing your page to the top frame.

Because essentially think about this like layers. If they have a clickjacking on your site and they have an invisible layer on top, people are entering it on there even though they think they’re on your site. By taking your site and forcing it to the top, that’s going to make sure they’re always inputting data in your site and not on the clickjack site. Now, one of the ways to do this is by using just a simple bit of JavaScript. For instance, if top does not equal self, then self location equals top location. This takes your layer and puts it on the top to prevent clickjacking.

Now, this will only work against the most simple framing abuse, but it is something good to put in there. There are more advanced iframe attacks that could use more advanced countermeasures using JavaScript as well. For instance, you could use X frame options. If you set your x frame options and set them to deny, this is actually a better strategy to protect against clickjacking. Now, when you do this, you have to make sure that this is in the header and deployed to every page in your domain. If you don’t do that, then the Clickjackers still have a way in and they can still take advantage of your customers.

10. Web Applications Vulnerabilities (OBJ 1.7)

Web application vulnerabilities. In this lesson we’re going to go through and do a little bit of analysis on the impact of web application vulnerabilities. Now as we do this, we’re going to take a look at a sample ecommerce website that’s going to involve a web front end and a database back end. So we’re first going to assess the database functionality, then we’re going to look at the website functionality. After that we’re going to test some injection vulnerabilities and then test some authentication application vulnerabilities. And by doing this, we’re going to be able to see if this website has any vulnerabilities that we need to address as a cybersecurity analyst. All right, let’s jump into the lab environment. First I need to test my database and my web server.So to do this I need to make sure they’re running.

So I’m going to type in service MySQL start and hit enter. Then I’m going to type in service Apache two Start and hit Enter. This is going to start both the database server and the web server on my staging environment. Now from here I’m going to open up the database administration using Firefox. To do this I’ll type in Firefox http localhostphp my admin and then Enter. At this point Firefox will load up and I’ll be brought to the login screen for PHP my admin. This is a web front end to interact with the back end database. From here we’ll be able to look at the tables inside the database and even run SQL queries. So all I’m going to do here is log in. Now that I’m in the back end, I can click on DevTech underscore Store, which is the database that I want to look at.

In here you can see there is new categories products and Users, and under Categories, Products and Users, those are my different tables. If I click on Categories, I can see here the different rows that I’m going to have inside that table. Essentially inside this table is a list of different product categories. Inside the ID column that’s going to be our primary key. And then the Name column is going to list the name of each of the different product categories. There are a total of nine different categories here. Notice you can see the SQL statement at the top it says Select Star from Categories. That is what we’re doing here. We’re selecting everything from the Categories table. Next, let’s select the Products table and review that data. Again, this is another table and it lists all the different products.

Instead of looking at the categories, we’re looking at the individual products. Here though each product has its own product code, description, price, and whether or not it’s going to be in stock and what category it belongs to. If we go and look at the Users table, we can look at that data. Inside of here we have a list of all the users who can sign into our website. Each user has a username, a password, a first name, a last name, and a level of permission. Now notice one major vulnerability here. We are storing our usernames and passwords in plain text. So if you look in the password column, you can see each person’s password. This is a very dangerous practice. Instead those passwords should have been hashed and then the hash should have been stored inside the database.

Now look at the URL that’s used to access this data. Notice it calls SQL PHP, and that’s a script that we’re going to use. It’s a PHP script. Now when it does this, it actually gives you parameters from the database. This is going to be something like the database, the table and the position within the table. So if we look under the SQL statement again here, we can click the edit link and from here we can change this SQL statement to say whatever we want. For example, if I want to see who has admin permissions, I can type in select star from users where permissions equals admin. And this will actually return just one record for us. This website is going to go into that database using scripting languages like PHP to pass those SQL statements in a secure way so the user can’t inject additional parameters.

Now, as we see this PHP My admin, this is an admin tool. This is not where our users are going to be inputting data. Instead they’re going to do it from the website. So let’s go ahead and take a look at the website itself. First we’re going to open the browser and go to http DevTech, which is a sample ecommerce website here inside my lab environment. Now this is the website for the store and it’s running on my local Apache web server that I started up at the beginning of this video. If you select the catalog tab, you’re going to be able to see all the products inside the monitors category. They’re all listed here from a table. Note that the URL here that’s used to serve this web page, it doesn’t have that SQL query anymore. Instead it says catalog PHP colon category equals one, which is selecting the first category which was monitors.

Now there are better ways of doing this, and this isn’t necessarily the most secure way or the least secure way, it’s just one way of doing things. Now here we’re actually passing in a parameter directly by saying category equals one. That means if this was something that was behind a secure Paywall, for instance, we wouldn’t want to do this because somebody could easily change that one to a two and that would select a different category directly. Next, I want to go ahead and try testing injection vulnerabilities. To do this, I’m going to put the website on the right side of my screen and the PHP My admin on the left side of my screen. Now, from here, what we’re going to do is we’re going to verify the URL that’s passing the parameters. In this case, category equals N.

In this case it was category equals one to make sure that we’re viewing the right category. So what I’m going to do is I’m actually going to go to the insertion point at the end of the URL and I’m going to add a space and then I’m going to type or one equals one, which as you remember from our lessons, one equals one is a very common way of doing an SQL injection. Now once we do this, we’re going to see what happens. Notice here that the listing page still says we’re in the monitors category, but we’re not seeing just monitors, we’re seeing every single product that this company has. That’s because we just injected this or one equals one, making every statement true and not just to display category one. This is a basic SQL injection.

Now notice in the SQL query section we can verify the query that we executed based on the URL we inserted from the web page. Notice that the query is selecting four columns from the products table. Anytime it finds the product category is N. In our case, one, or where one equals one. And because one equals one every single time, guess what, it’s going to dump every single category all at once to the screen. Now that we’ve tested injection vulnerabilities, let’s go ahead and test an authentication vulnerability. We’re going to go into the sign in tab and we’re going to attempt to sign in as Kevin. Now when we try to sign in, if we don’t know his password, we’re going to get an error and it’s not going to let us sign in.

Now we don’t have the ability to crack his password at this point, so instead, let’s try an SQL injection. Now here we’re going to put Kevin as the username and try to put something in the password field to cause the malicious SQL statement to be formed. This is an SQL injection. So if I do something like X and then a quote space or space quote xquote equals quote X, that will be able to do an SQL injection for us because the quote is going to break apart from that password and then test the second half of the statement or something equals something. And so let’s see how this looks. Now to see what I actually typed in, we’re going to go and right click on the field and do inspect element. This will allow us to see what was there inside of the field.

In HTML, when it’s a password field, it’s going to show up with stars or dots instead of the text. So I’m going to change that password field to text and that will allow us to see what I actually put in. So now we’ll go ahead and click on the sign in button and you’ll see that it sends that to the SQL database and we get back an error inside the database giving us a warning saying that there was a parameter of one to be expected. But instead we got the results of Varwwtechoretmlsignin PHP on line 37. Essentially we caused an error in the program by doing this injection, but we were still able to successfully sign in. Now notice we are logged in, but we’re not logged in as Kevin. It says welcome comma space period. It doesn’t say welcome, Kevin.

Why is that? Well, because our malicious query took advantage of the default Apostrophe formatting and because there was no sanitized input, because they didn’t do input validation, I was able to do an SQL injection. By doing that. It’s going to go and look for the first authentication in the table.In our case, that first person is actually going to be Laura Anderson, and that’s the person who has administrative privileges. So we are now logged in as Laura Anderson, the database administrator. So you can see how powerful SQL injections can be and how easy they are to conduct when somebody doesn’t do the right protections on their website, either on the front end using input validation through the website, or on the back end when they don’t have things configured quite right.

Now, in Cysaplus, it’s not your job to figure out how to fix all these things, but it is your job to figure out if they’re vulnerable to these types of attacks. And so you need to understand what SQL injection is. And usually when you see something like one equals one or x equals X, that’s a dead giveaway. Now on the exam, if you’re asked how to fix something like this, the best answer is going to be input validation. If they had done input validation on the website and took away my ability to insert that Apostrophe, it would have prevented this SQL injection from occurring in the first place.