Difference between revisions of "XSS"

Revision as of 03:14, 31 August 2012

Introduction

X(cross) Site Scripting is the injection of arbitrary HTML, CSS, or JavaScript into a page via an HTTP input or a SQL database.

The most common is with a GET request to a vulnerable site, however other times an attacker may embed the attack inside of a SQL 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’]);

The above PHP code is vulnerable. Do not use this on your site!

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.

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.