Difference between revisions of "XSS"

Latest revision as of 03:35, 20 September 2012

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".

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:

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

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.

Use these techniques RESPONSIBLY. Do not use these techniques for FUN or for any TYPE of malicious act, as it will criminalize you.