XSS: What is Cross-site Scripting? Lesson 1, Basics

Cross-site Scripting is the third vulnerability on the OWASP Top 10 and it is a vulnerability that can allow an attacker to steal confidential data, execute functions on a vulnerable site, virtually deface a site or redirect the user to a malicious page.

The vulnerability comes about because user input is insecurely embedded in a response to the user; this is partly due to the simple way in which web browsers differentiate between text and code. Consider a page like http://xxs.example.com/?name=Holly which has the following web page HTML:

 <html><body><p>Hello Holly! Welcome!<p></body></html> 

Web browsers utilise < and > characters to determine what is code and what is text. In the above example you can see the code “tags” such as <html> are wrapped around the text “Hello there!”. So above the browsers interpretation of what is code is shown in green and what is text is shown in blue. However instead of Holly, if I enter my name as Holly<script>alert(“Vulnerable!”)</script> the page that would be given to the web browser would look like this:

<html><body><p>Hello Holly<script>alert("Vulnerable")</script>! Welcome!<p></body></html> 

As you can see, even though the script tags originated from user input and were supposed to be interpreted as simple text, as they contained those important < and > characters, the web browser has interpreted them as code and not text! This means that code has sneaked its way in from the URL in the case into the body of the page as the site did not protect against this vulnerability.

This means that an attacker can craft a malicious link which contains scripts designed to attack the user, if a user is coerced into clicking the malicious link then the attacker’s payload could fire. The payload could steal the victim user’s session credentials from their cookie, deface the pay or redirect the user to a malicious site.

If the attacker’s payload is immediately returned to the user, for example when a user clicks a link the payload fires – then this is known as Reflected Cross-site Scripting. As the payload bounces, or is reflected, on the server and delivered to the victim.

Alternatively the same kind of attack can be achieved in a function such as a guestbook or forum where an attacker can save a payload and simply wait for a victim to stumble across it as they navigate the vulnerable site. This type of deployment is called Stored Cross-site Scripting.

Defending against Cross-site Scripting

The vast majority of XSS can be fixed in a relatively simple way, by encoding all dangerous characters that originated as user input using HTML entity encoding. The benefit of HTML entities is that the browser will show the correct character to the user but it’ll prevent an attacker from injection scripts. HTML entities look like this:

< <
> >
' '
" "

If the original payload shown earlier in the page was encoded in this way it would render in the web page code like this:

 <html><body><p>Hello Holly&ltscript&gt;alert("Vulnerable")&lt;/script&gt;! Welcome!<p></body></html>

Although it’d look a little messy – it certainly would protect the user from the attacker’s payload!

Read More