Don't XSS me!

Cross site scripting is a type of attack wherein a malicious script is injected and executed in a users browser and the payload can be as dangerous as hijacking a users valid session. XSS does not really rely on web browser or operating system vulnerability but it specifically targets the web application flaws in handling inputs. In this post i will highlight some of the mitigation's and some well known facts about XSS.

When this vulnerability was first discussed it was considered as a lame horse in front of big giants like SQL injection until in October 04 2005 when the sammy worm took myspace in just few hours. More details on this xss worm can be found here

Its not always required to insert a <script> tag for xss to work, sometimes <script> tag may be stripped off by application filters making your payload useless.
Few more ways:
a)<IMG SRC=j&#X41vascript:alert('hello')>

b)<img src="http://url.to.file.which/not.exist" onerror=alert(document.cookie);>

c)';alert(String.fromCharCode(88,83,83))//\';alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCode(88,83,83))//\";alert(String.fromCharCode(88,83,83))//--></SCRIPT>">'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>

For more awesome vectors see this link Rsnake XSS

This portion of the article would benefit most of the developers who would think of security as a

major aspect than a fancy UI. Some of the important things that a developer should keep in mind

before starting any web application assignment is that whatever input is collected from the client

side cannot be trusted. Most web applications that do not need to accept rich data can use escaping to largely eliminate the risk of XSS in a fairly straightforward manner.Have a look at XSS prevention cheat sheet here. The OWASP Esapi Library is highly recommended for preventing Cross site scripting attacks.

Some new attack vectors:

Recently i came across this blog entry which describes a new way of looking into XSS attacks.
Here the attack is more towards tweaking parameter names rather than the parameter values.

The conventional way an attacker would try!

http://abc/test.aspx?a=<script>
alert('xss')</script>

But in ASP.Net application the ValidateRequest is enabled by default which would strip out the HTML

mark ups and pop up an error as shown below.

However, if we instead place our attack payload into a parameter name, then ValidateRequest allows

our input through and we hit the vulnerable code:
http://abc/test.aspx?<script>
alert('xss')</script>=a