Difference between revisions of "XSS"

Revision as of 11:38, 10 November 2011

Introduction

X(cross) Site Scripting

There are several vectors for an attacker to deploy a cross site scripting attack.

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.

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.

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 :

 echo($_GET[‘header’]);

This can be exploited when an attacker requests the URL:

 /xss.php?header=javascript:alert(“XSS”);

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

Because the domain name is in the URL, it is rare that a user will think twice about trusting the link.

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 s/he 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 ?[variabl]=[value] or any &[variable]=[value] pair inside every URL on the entire site. The values to the variables are the important parts. Remember, in SQL injection, one find vulnerable sites by putting %27 on the end of any [value] or just putting a %20AND%201=0 on it?

This time, to scan for XSS, lets reset every [value] for every [variable] 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.

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 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 filter. If ' or " slip through, attributes to the tags can be assigned. If () and ; slip through, 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. If an XSS vulnerability is found, chances are Apache is vulnerable to the off-by-one buffer overflow exploit.

XSS Exploitation

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

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

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.

External links

• XSS Cheat Sheet