In discussions about security testing, you have probably heard about Cross-Site Scripting (XSS), but you may not have a good definition of what it is. Cross-Site Scripting is an attack in which a malicious user finds a way to execute a script on another user’s website. Today we’ll learn about two different kinds of XSS attacks, do a hands-on demo of each, and discuss why they are harmful to the end user.
Reflected XSS:
Reflected XSS is an attack that is executed through the web server, but is not stored in the code or the database. Because the attack is not stored, the owner of a site may have no idea that the attack is happening.
In order to demonstrate this attack, we’ll go to a great training site from Google called the XSS Game. This site has a series of challenges in which you try to execute XSS attacks. The challenges become increasingly more difficult as they progress. Let’s try the first challenge.
On this page, you see a simple search field and button. To execute the attack, all you need to do is type
<script>alert(“XSS here!”)</script>
into the text field, and click the button. You will see your message, “XSS here!”, pop up in a new window.
What is happening here is that you are sending a script to execute a popup alert to the server. The client-side code does not have appropriate safeguards in place to prevent a script from executing, so the site executes the script.
You might be thinking “This is a fun trick, but how could a malicious user use this to hack me? I’m typing into my own search window.” One way this is used is through a phishing link. Let’s say that you are the owner of a website. A malicious user could create a link that goes to your site, but appends a script to the end of the URL, such as
?query=%3Cscript%3Ealert%28%22XSS%22%29%3C%2Fscript%3E.
(This is simply the attack we used earlier, with HTML encoding.) The malicious user could send this link in an email to an unsuspecting visitor to your site, making the email look like it came from you. When the person clicks on the link, the script will navigate to your site, and then execute the popup script. The malicious user will craft the script so that instead of containing the message “XSS here!”, it contains a message that encourages the visitor to interact with it, in order to obtain the user’s account number, or other sensitive information.
Stored XSS:
Stored XSS is an attack where the malicious script is actually stored in the database or code of a website, so it executes whenever a user navigates to the page or link. This could happen if the creator of the site did not put adequate input sanitization in the back-end database.
We’ll take a look at how to craft this attack by looking at the second challenge of the XSS Game. (In order to see this challenge, you’ll need to have solved the first challenge, so follow the instructions above.)
In the second challenge, you are presented with a chat app. To solve the challenge, you need to add some text to the application that will execute a script. You can do this by typing in
<img src=’foobar’ onerror=’alert(“xss”)’>
As soon as you submit this entry, you should see a popup window with the “XSS alert!” message. And not only that, if you navigate away from this page and return to it, you will see the popup window again. The attack has been stored in your comment on the chat page, where it will cause a popup for any users who navigate to it.
Let’s parse through the script we entered to see what it’s doing:
<img src=’foobar’ onerror=’alert(“xss”)’>
The items in red indicate that we are passing in an image element.
<img src=’foobar’ onerror=’alert(“xss”)’>
The section in blue is telling the server what the source of the image should be. And here’s the trick- there is no URL of foobar, so the image cannot load.
<img src=’foobar’ onerror=’alert(“xss”)’>
The section in green is telling the server that if there is an error, that a popup window should be generated with the “xss” text. Because we have set things up so that there will always be an error, this popup will always execute.
One way that stored XSS might be used is to spoof a login window. When a user navigates to a hacked site, they will be presented with a login window that has been crafted to look authentic. When they enter their login credentials, their credentials will be sent to the malicious user, who can now use them to log in to the site, impersonating the victim.
Next week, we’ll discuss more ways to test for XSS attacks!