Questions about this topic? Sign up to ask in the talk tab.

Difference between revisions of "XSS"

From NetSec
Jump to: navigation, search
(Testing for XSS)
 
(33 intermediate revisions by 6 users not shown)
Line 1: Line 1:
 +
{{inprog}}
 +
<font size="-2">Special thanks to [[User:Xochipilli|xo]] for his contributions to this article.</font>
 
== Introduction ==
 
== Introduction ==
<b>X</b>(cross) <b>S</b>ite <b>S</b>cripting
+
<b>X</b>(cross) <b>S</b>ite <b>S</b>cripting is the injection of arbitrary [[HTML]], [[CSS]], or [[JavaScript]] into a page via an [[HTTP]] request, a server side [[database]], or client side scripting. The injected code can then perform several actions which appear to originate from the vulnerable server or execute scripted actions on the vulnerable site using the victim's authentication.
  
There are several vectors for an attacker to deploy a cross site scripting attack.
+
There are several [[Web_Exploitation#Attack_Vectors|vectors]] for cross site scripting attack deployment. They are typically categorized into three types. The types are each referred to by several names as there is no standardized naming scheme for cross site scripting implementations.
  
The most common is with a GET request to a vulnerable site, however other times an attacker may embed the attack inside of a [[database]] used to store dynamic content. For example, web sites like LiveJournal, MySpace, DeviantArt, and Pathetic.org all host dynamic user [[input]] that the user submits in the format of text on a form.
+
=== Type 0: DOM Based ===
  
On MySpace, [[CSS]] can be used to control styling and other options for user submitted data. Not long ago, MySpace was using a faulty <EMBED> tag to hold their flash login page. Attackers used this [[vulnerability]] to insert their own <EMBED> tag into the [[CSS]] handler that stored their styles, creating a fake login page and tricking normal users into submitting their username and [[password]] into the attacker’s [[database]].
+
=== Type 1: Non-Persistent or Reflected ===
  
Oftentimes a web site is vulnerable to XSS when using [[input]] directly from a GET or POST method. xss.php, a vulnerable site, might contain code (in PHP) similar to :
+
Reflected XSS refers to a type of cross site scripting that originates from the victims browser. These types of attacks are not stored on the vulnerable site and usually originate as a link or form submission provided by various social engineering techniques leading the victim to clicking the offending link or form submission.
{{code|text=
+
<syntaxhighlight lang="php">
+
<?php
+
  echo($_GET[‘header’]);
+
?></syntaxhighlight>
+
}}
+
  
This can be exploited when an attacker requests the URL:
+
Typically this uses GET requests which is the most commonly seen method. GET request XSS attacks can be seen by the victim as the XSS payload is sent within the URL. POST requests can be used as well and are much harder to detect by the victim since the data used to initiate the XSS attack is sent separate from the URL and is embedded in source if the page it resides on.
  
  <nowiki>/xss.php?header=javascript:alert(“XSS”);</nowiki>
+
In these types of XSS attacks,  the user must be persuaded into follwing the attacker's URL that contains the XSS attack or in the case of POST request XSS, the victim must be coaxed into submitting the hidden XSS form data that is included in the source of the page it resides on.
  
The above URL will open a message box window with the caption “XSS” when a victim user is tricked into clicking on a link. Even though this example only makes a message box, [[JavaScript]] can be used to steal [[cookies]], inject multi-site shared [[cookies]], inject ActiveX objects, and to perform a [[Buffer Overflows|buffer overflow exploit]]. This technique can also be used in conjunction with [[CSRF]], when combined becoming [[XSRF]], to allow the attacker to perform actions in the context of the authenticated user on the site.
+
In a hypothetical scenario there is a server with the domain vulnerable.tld, it contains a script called xss.php which is vulnerable to XSS attacks.
  
Because the domain name is in the URL, it is rare that a user will think twice about trusting the link.
+
vulnerable.tld/xss.php?user=Username
  
----
+
In normal operation the variable "user" normally would contain a username to produce html that contains a greeting.
 +
 
 +
Hello Username,
 +
 
 +
In the following examples Reflected XSS is used to create a popup alert that appears to originate from vulnerable.tld.
 +
 
 +
==== GET ====
 +
GET methods place the XSS payload into the URL that the victim visits.
 +
 
 +
{{code|text=<source lang="javascript">
 +
<a href="http://vulnerable.tld/xss.php?user=%3Cscript%3Ealert(XSS%20Example)%3C%2Fscript%3E">Click Me!</a></source>}}
 +
 
 +
On visiting the attacker's provided URL.
 +
 
 +
vulnerable.tld/xss.php?user=<script>alert(XSS Example)</script>
 +
 
 +
the victim would recieve a popup alert with the message "XSS Example" as the webpage's dynamic html would contain.
 +
 
 +
Hello <script>alert(XSS Example)</script>,
 +
 
 +
==== POST ====
 +
A POST method requires data to be sent in the message body of the POST request,  usually originating from form data on the attacker's page. Here is a scenario similar to the prior example, using using a POST request to achieve the same results.
 +
 
 +
{{code|text=<source lang="javascript">
 +
<form method="POST" action="http://vulnerable.tld/xss.php" name="example" >
 +
<input type="hidden" name="user" value="%3Cscript%3Dalert(XSS%20Example)%3C%2Fscript%3E" />
 +
<input type="submit" value="Submit" />
 +
</form>
 +
</source>}}
 +
 
 +
On clicking submit,  this would produce the same results as the prior example. Unlike the GET request, the XSS is less noticeable as the URL doesn't contained the payload.
  
 +
=== Type 2: Persistent or Stored ===
  
  
 
  
 
== Testing for XSS ==
 
== Testing for XSS ==
Line 42: Line 68:
 
In other words, we're looking for any of the following two:
 
In other words, we're looking for any of the following two:
  
<pre>?[variabl]=[value]</pre>  
+
<pre>?[variable]=[value]</pre>  
 
or  
 
or  
<pre>&[variable]=[value]</pre>
+
<pre>&[variable]=[value]</pre>
  
inside every URL on the entire site. The values to the variables are the important parts. Remember, in [[SQL injection]], one finds vulnerable sites by putting %27 on the end of any <b>[value]</b> or just putting a %20AND%201=0 on it?
+
inside every URL on the entire site. The values to the variables are the important parts.
  
This time, to scan for XSS, lets reset every <b>[value]</b> for every <nowiki>[variable]</nowiki> to AAAaaabbCCddD. Why such a random character combination? Because a random character combination like that should never randomly show up in a site's source code. Once the url has been modified, go ahead and click it, after which right click on the site and view the source code.
+
This time, to scan for XSS, lets reset every <b>[value]</b> for every <b>[variable]</b> to "AAAaaabbCCddD".  
  
Search for the string AAAaaabbCCddD, because no one will randomly have that in their source code. If its there, modify the value from AAAaaabbCCddD to <nowiki>">'"();><</nowiki> and determine how many characters make it through. Due to filtering, sometimes these characters (used during attacks) are stripped to their [[HTML]] counterparts.  If the less than and greater than sign appear in the affected area of code, one knows that [[HTML]] tags can slip through the filterIf ' or " slip through, attributes to the tags can be assignedIf () and ; slip through, javascript injection is possible.
+
{{info|In [[SQL injection]], one finds [[vulnerability|vulnerable]] sites by putting a '''single quote''' on the end of any value or just tacking a '''%20AND%201&#61;1''' on the end of it.}}
 +
 
 +
 
 +
Why such a random character combination? Because a random character combination like that should never randomly show up in a site's source code.
 +
Once the url has been modified, go ahead and click it, after which right click on the site and view the source code.
 +
 
 +
Search for the string AAAaaabbCCddD, because no one will randomly have that in their source code. If its there, modify the value from AAAaaabbCCddD to:
 +
 
 +
{{code|text=">'"();><}}
 +
 
 +
and determine how many of these characters make it through.
 +
 
 +
Due to filtering, sometimes these characters (used during attacks) are stripped to their [[HTML]] counterparts.   
 +
 
 +
If the following signs appear in the affected area of code, one knows that [[HTML]] tags can slip through the filter:
 +
{{code|text=
 +
<b>
 +
<
 +
>
 +
</b>
 +
}}
 +
 
 +
If these following characters slip through, attributes to the tags can be assigned:
 +
{{code|text=
 +
<b>
 +
'
 +
"
 +
</b>
 +
}}
 +
 
 +
If any of these characters slip through, we know that [[JavaScript]] injection is possible:
 +
{{code|text=
 +
<b>()</b>
 +
<b>;</b>
 +
}}
 +
 
 +
This method will also work to fuzz a website for [[SQL injection]] holes.
 +
Just scan the ENTIRE site, every single possible request variable and value for a [[vulnerability]], and usually, in less than one hour, you're in.
 +
 
 +
In case there seems to be no file extensions whatsoever, start [[fuzzing]] each directory name and filename, this could be an apache setup with mod_rewrite.
  
This method will also work to fuzz a website for [[SQL injection]] holes. Just scan the ENTIRE site, every single possible request variable and value for a [[vulnerability]], and usually, in less than one hour, you're in. In case there seems to be no file extensions whatsoever, start [[fuzzing]] each directory name and filename, this could be an apache setup with mod_rewrite. If an XSS [[vulnerability]] is found, chances are Apache is vulnerable to the off-by-one [[Buffer Overflows|buffer overflow exploit]].
 
 
----
 
----
  
Line 63: Line 127:
 
     echo("<input type='text' value='$_GET['search']'>");
 
     echo("<input type='text' value='$_GET['search']'>");
 
?></syntaxhighlight>
 
?></syntaxhighlight>
}}
+
}}{{warning|The above code is [[vulnerability|vulnerable]].  Do not use this on your own site.}}
  
 
A simple attack might involve requesting the following:
 
A simple attack might involve requesting the following:
Line 80: Line 144:
 
Fixes for these vulnerabilities can be found in [[PHP Patching]].
 
Fixes for these vulnerabilities can be found in [[PHP Patching]].
  
Use these techniques RESPONSIBLY. Do not use these techniques for FUN or for any TYPE of malicious act.
+
{{warning|Use these techniques RESPONSIBLY. Do not use these techniques for FUN or for any TYPE of malicious act, as it will criminalize you.}}
 +
 
 +
{{exploitation}}
 
----
 
----
  
 
+
== See Also ==
 
+
* [[Unsafe string replacement]]
  
 
==External links==
 
==External links==
 
* [http://ha.ckers.org/xss.html XSS Cheat Sheet]
 
* [http://ha.ckers.org/xss.html XSS Cheat Sheet]
[[Category:Web Exploitation]]
+
 
 
{{series
 
{{series
 
| Name = XSS
 
| Name = XSS
 
| PartOf = Web Exploitation
 
| PartOf = Web Exploitation
 
}}
 
}}
 +
[[Category:Web exploitation]] [[Category:Exploitation]]

Latest revision as of 03:35, 20 September 2012

RPU0j.png
XSS is currently in-progress. You are viewing an entry that is unfinished.

Special thanks to xo for his contributions to this article.

Introduction

X(cross) Site Scripting is the injection of arbitrary HTML, CSS, or JavaScript into a page via an HTTP request, a server side database, or client side scripting. The injected code can then perform several actions which appear to originate from the vulnerable server or execute scripted actions on the vulnerable site using the victim's authentication.

There are several vectors for cross site scripting attack deployment. They are typically categorized into three types. The types are each referred to by several names as there is no standardized naming scheme for cross site scripting implementations.

Type 0: DOM Based

Type 1: Non-Persistent or Reflected

Reflected XSS refers to a type of cross site scripting that originates from the victims browser. These types of attacks are not stored on the vulnerable site and usually originate as a link or form submission provided by various social engineering techniques leading the victim to clicking the offending link or form submission.

Typically this uses GET requests which is the most commonly seen method. GET request XSS attacks can be seen by the victim as the XSS payload is sent within the URL. POST requests can be used as well and are much harder to detect by the victim since the data used to initiate the XSS attack is sent separate from the URL and is embedded in source if the page it resides on.

In these types of XSS attacks, the user must be persuaded into follwing the attacker's URL that contains the XSS attack or in the case of POST request XSS, the victim must be coaxed into submitting the hidden XSS form data that is included in the source of the page it resides on.

In a hypothetical scenario there is a server with the domain vulnerable.tld, it contains a script called xss.php which is vulnerable to XSS attacks.

vulnerable.tld/xss.php?user=Username

In normal operation the variable "user" normally would contain a username to produce html that contains a greeting.

Hello Username,

In the following examples Reflected XSS is used to create a popup alert that appears to originate from vulnerable.tld.

GET

GET methods place the XSS payload into the URL that the victim visits.

 
<a href="http://vulnerable.tld/xss.php?user=%3Cscript%3Ealert(XSS%20Example)%3C%2Fscript%3E">Click Me!</a>

On visiting the attacker's provided URL.

vulnerable.tld/xss.php?user=<script>alert(XSS Example)</script>

the victim would recieve a popup alert with the message "XSS Example" as the webpage's dynamic html would contain.

Hello <script>alert(XSS Example)</script>,

POST

A POST method requires data to be sent in the message body of the POST request, usually originating from form data on the attacker's page. Here is a scenario similar to the prior example, using using a POST request to achieve the same results.

 
<form method="POST" action="http://vulnerable.tld/xss.php" name="example" >
<input type="hidden" name="user" value="%3Cscript%3Dalert(XSS%20Example)%3C%2Fscript%3E" />
<input type="submit" value="Submit" />
</form>
 

On clicking submit, this would produce the same results as the prior example. Unlike the GET request, the XSS is less noticeable as the URL doesn't contained the payload.

Type 2: Persistent or Stored

Testing for XSS

Cross Site Scripting (XSS) is a vulnerability found in pages that return user input inside the HTML code sent back from the server.

To make a long story short, this allows an attacker to craft a link to a domain and put any content on that domain that he or she desires.

Testing for these vulnerabilities can be done rather easily. These security flaws are most prevailent in ASP/PHP/CGI powered sites. These vulnerabilities may also exist in sites that do not appear to run on ASP/PHP/CGI thanks to things such as apache's mod-rewrite and microsoft's IIS ISAPI filters.

Because not all sites are obviously run on this, sometimes when scanning we'll have to use advanced methods. Security101 covers basic to intermediate methods of fuzzing for Cross-Site Scripting (XSS) vulnerabilities and basic exploit methods.

To fuzz for a XSS vulnerability in a remote file, one has to look for every single variable that the site uses in GET requests for user-input. In other words, we're looking for any of the following two:

?[variable]=[value]

or

&[variable]=[value]

inside every URL on the entire site. The values to the variables are the important parts.

This time, to scan for XSS, lets reset every [value] for every [variable] to "AAAaaabbCCddD".

c3el4.png In SQL injection, one finds vulnerable sites by putting a single quote on the end of any value or just tacking a %20AND%201=1 on the end of it.


Why such a random character combination? Because a random character combination like that should never randomly show up in a site's source code. Once the url has been modified, go ahead and click it, after which right click on the site and view the source code.

Search for the string AAAaaabbCCddD, because no one will randomly have that in their source code. If its there, modify the value from AAAaaabbCCddD to:


">'"();><

and determine how many of these characters make it through.

Due to filtering, sometimes these characters (used during attacks) are stripped to their HTML counterparts.

If the following signs appear in the affected area of code, one knows that HTML tags can slip through the filter:

< >

If these following characters slip through, attributes to the tags can be assigned:

' "

If any of these characters slip through, we know that JavaScript injection is possible:

() ;

This method will also work to fuzz a website for SQL injection holes. Just scan the ENTIRE site, every single possible request variable and value for a vulnerability, and usually, in less than one hour, you're in.

In case there seems to be no file extensions whatsoever, start fuzzing each directory name and filename, this could be an apache setup with mod_rewrite.


XSS Exploitation

Sometimes the input is echoed in the middle of an HTML tag, for example:

<syntaxhighlight lang="php"> <?php

    echo("<input type='text' value='$_GET['search']'>");

?></syntaxhighlight>

RPU0j.png The above code is vulnerable. Do not use this on your own site.

A simple attack might involve requesting the following:

  /xss.php?header=search&search=' onMouseOver='alert("xss");

When the php echoes out the html, the code will be come:

<input type='text' value='' onMouseOver='alert("xss")'>

Sometimes programmers patch the software incorrectly. They wrap user input inside the page in <noscript> tags because they don't know how to use regular expressions or proper sanitizing techniques. Attackers can bypass this very easily:

 /xss.php?u=</noscript>

To see if they can bypass the filter, just because programmers have incorrectly thought its proper to sanitize user input with that method. That's the basic overview of XSS exploitation.

Fixes for these vulnerabilities can be found in PHP Patching.

RPU0j.png Use these techniques RESPONSIBLY. Do not use these techniques for FUN or for any TYPE of malicious act, as it will criminalize you.
XSS is part of a series on exploitation.

See Also

External links



XSS
is part of a series on

Web Exploitation

Visit the Web Exploitation Portal for complete coverage.