XSS Browser Filter Mitigation

I’ve recently become interested in XSS or Cross Site Scripting which is the process of executing arbitrary javascript on a website. It’s fairly simple and is interesting if you try it on websites you visit as a habit. This however got fairly boring fairly quickly as there are XSS vulnerabilities everywhere, I found one in the Bank of Queensland’s website (which is now gone sadly).  Because of the prevalence of XSS vulnerabilities browsers such as chrome, safari and internet explorer have started protecting users against these attacks. This link: translate XSS will not work in chrome, safari or internet explorer but it will work in firefox. This has led me to an interesting topic, XSS Browser Filter Mitigation. That’s the process of executing arbitrary javascript despite the browser protection.

There are some well known bypasses for chrome (and safari), these include executing javscript when you have control over two variables: From There is an example on my own website: here That link spreads the XSS attack over the variables a and b, completely removing the protection of chrome and safari. However Internet Explorer protects against this. Another attack on chrome’s protection is by using its html cleanup to execute javascript: From Another example is on my website: here However internet explorer still defeats it.

These general attacks are extremely cool and much Kudos to the people who discovered them. I’ve been looking at specific attacks which get round these filters. By specific I mean they only target specific websites. So how does one get around XSS filtering. The thing I realised (someone may have helped me realise this, I don’t know/can’t remember) is that if any data undergoes translation from input to output then the browser can’t protect against it as the browser can’t be aware of the translation that it undergoes. This isn’t exactly amazing or groundbreaking but it is interesting. The very first thing I tried was to get an XSS attack working for chrome on http://www.motobit.com/util/base64-decoder-encoder.asp  The first step was to encode the attack into a base64 string. </textarea><script>alert(‘hi’)</script> gets encoded to PC90ZXh0YXJlYT48c2NyaXB0PmFsZXJ0KCdoaScpPC9zY3JpcHQ+ If you decode that string you will get an alert saying hi. So success! (Auto submit)

I’ve found interesting vulnerabilities since discovering this. This includes a pig latin translator and other translators. Converters are generally vulnerable. However one particular  specific attack made me very amused. It uses an SQL injection vulnerability (and yes if your website has an SQL Injection Vulnerability in it then you have a lot more problems than arbitrary javascript execution. The attack is against MoreRFID.com and it selects a hexstring and dumps it to the page. The link is here (remember kids, data theft is illegal).

I like these attacks because it firmly places the responsibility of protecting the page back on the web developer. Browser filtering should not be an excuse for poor security. If you are a web developer who takes data and manipulates it in someway you need to be aware of these types of attacks and always escape your output.


, , , , , ,

  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: