Cross Site Scripting (XSS)
Simply put, cross site scripting (XSS) involves the injection of malicious code into a website. It is one of the most common methods of attack, as most large sites will contain at least one XSS vulnerability. However, there is more than one type of XSS. The most commonly occuring is referred to as "non persistent" XSS.
None Persistent XSS
None 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. A good example of this is a basic coded search engine for a site. Say for example, the site search URL is in this format:
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 contain HTML or JavaScript? For example:
OR:
If no sanitation checks are being performed by the search script, this will be echoed straight onto the page, therefore displaying an alert or red text. If there was no limit to the string size, this could be used to display anything you want.
However, since the attacker can only display XSS with a custom link, 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 example may be a register form not sanitizing input allowing users with HTML or JavaScript in their names to be created. This would then be run everytime the "user" is displayed on the page, affecting legitimate users of the site.
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 images[number].src and anyone who is a web developer will know the effects of changing styling (CSS) for a site. If you have a permanently vulnerable script, injecting code as simple as the one below will allow you to run XSS from an external location:
Circumventing Basic Protection
So what if a site owner knows about XSS, and has implemented some very basic 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 example 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))//--></script>">'><script>
alert(String.fromCharCode(88,83,83))</script>
This is very useful XSS to know, as it provides more than one type of attack. If you get only one or two alerts, you know that only one of two of the methods work, so you need to eliminate some of them to text which one is successful. The CharCode for "X" is 88 and "S" is 83. As you can see, each provides a slight variation to try to beat basic character blocking.
JavaScript XSS could also be executed almost anywhere, including in an image tag. This code below would run malicious JavaScript disguised as an image:
What if quotes are blocked? No problem, the following can be used:
The " will be interpreted in HTML as a " so the code will run fine. The next one below is more likely to work on a vulnerable site:
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 look at ASCII and Unicode. Unicode was designed to allow all characters to be viewable to everyone e.g. for different languages such as chinese character symbols. ASCII is similar but with a smaller character set. You can go to: http://www.asciitable.com
To view the ASCII character table. This below shows the whole code in ASCII form:
As you can tell, this will beat many filters as the code is basically unrecognisable. However, de-converting the code can show what it was designed to do. Next for Unicode, again this makes the text unrecognisable but works the same:
If the site has a maximum 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:
Again unrecognisable which decreases the chance of detection.
With so many ways to bypass security checks developers have to work harder to try to protect their sites. As well as web forms being common allowing users to enter data 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 allows login info to be stolen or if sessions are used perform "session hijacking" where another users SESSION is stolen, effectively allowing full access to their user account. To the simple defacement of a website through HTML or Javascript. XSS provide many entry points and possible methods of attack.
This tutorial is only a starting point but I will finish with providing some more common XSS examples that can be performed.
New line vulnerability.
iFrame used to display an external site embedded in the page.
Another JavaScript injection method used to bypass filtering.
Infected body tag.
Bgsound injection (obselete).
Stylesheet injection.
VB Script, a scripting language similar to javascript, could bypass JavaScript filter checks.
Incorrectly parsed meta refresh.
Base64 encoded injection.
Sneaky method, rename .js to .jpg, but since it is in script tags it will still be read as a js file.
The list could go on and on. A lot of the time incorrectly written HTML code that is still parsed on executed in browser 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 start the malicious code.
That concludes this tutorial. Try to invent some of your own based on the examples above.