XSS ME! (vulnerable param: GET['xss'])

List of Glory:

1. @garethheyes solved it (2011-09-22) #bypass fixed (not in Safari 5.x though - buggy browser is buggy)
   • Gareth's vector essentially looked like this: ?xss=%20name=getElementsByTagName%20onerror=alert(1)%20. It worked perfectly in all browsers. Why? The answer is simple - modern browsers as well as the older ones create references for HTML elements in the DOM in case certain criteria are met. Gareth gave the image a name attribute. So the image is supposed to appear as a variable in the DOM - precisely a child of document. Try it out - it works. I should have known since I published on that in 2008. Doh. Most people know that id attributes are dangerous -- name is still allowed by many filters nevertheless.
     
     Imagine <img src=whatever name=test> result in the image being contained in document.test. Since the browsers don't really care if something with the same name already exists, they overwrite what's there and thus transform document.getElementsByTagName() into a property pointing to the image tag - rather than a function. So my loop didn't work anymore, the sanitation broke and he successfully bypassed my filter code. Job well done :)
     
     My fix made sure that getElementsByTagName was frozen. Later I changed it to querySelectAll.
     
     
2. @kinugawamasato solved it (2011-09-22) #bypass fixed
   • Masato used a similar trick and overwrote DOM properties I was using in my loop by URL (!!!). Yet another brilliant example how JavaScript interruption vulnerabilities will affect future solutions for securing user input and sanitizing the DOM. The fix was to forbid Internet Explorer to work in a document mode other than standards mode.
     
     I added a meta tag and X-Frame-Options header to force IE to stay in IE9/10 mode and act nicely.
     
     
3. @thewildcat solved it (2011-09-22) #bypass fixed
   • His vector bypassed my filter script by using the same technique Gareth applied without having seen the vector -- and after I fixed Gareth's bypass. Classic. He simply overwrote the attributes attribute of the image tag causing the loop to fail. The result was my code attempoting to loop over image.attributes - but finding only a single attribute property rather than an array. Overwriting attributes by making it an attribute. Priceless. Exception, business logic was broken, code was bypassed. Awesome work! ?xss=%0Aname=attributes%0Aonclick=alert(1)%0A My fix was here to set the doctype for IE to force it to render in IE9 mode -- and adding the mentioned frame headers. This specific attack is as far as I know only possible in older document modes.
     
     
4. @shafigullin solved it (2011-09-23) #bypass fixed
   • Roman's vector was simply priceless and I completely did not expect this to work. He -- before I got scared and added X-Frame-Options headers -- IFramed the challenge website in a sandboxed Iframe, injected a link containing a href with a JavaScript URI and then - after my page had loaded allowed and the script business logic failed due to the sandbox, enabled JavaScript for the IFrame again. Thus my code did not run -- but the JavaScript URI could be clicked again.
     
     That whole thing is to my knowledge a new attack against sandboxed IFrames. Roman created a ticket for the Chrome guys because.. it kinda doesn't feel like desired behavior -- additionally it didn't work on IE10.
     
     Here's his code: http://pastebin.com/LcgtGdwM
     
     
5. @garethheyes solved it again. Three times. (2011-09-24) #bypass fixed
   • This time it was onpropertychange working on IE9 and thereby effectively using the code against itself. With injecting an onpropertychange event handler, Gareth managed to make sure that the sanitation itself caused the JavaScript execution. A link getting it's malicious href removed will cause what? A call of its propertyChange event of course. Triple doh! Code bypassed.
     
     The fix here was to change the onpropertychange before the change to the other attributes happend. Onpropertychange does not register changes to itself. Therefore the issue was fixable at all -- which I first doubted a bit to be possible :)
     
     I am not sure yet if I can publish the other ones -- since it's pretty specific browser bugs. One I knew about (Doh again!), one I didn't. I'll ask though. Stay tuned.
     
     Hint: I added type="text/javascript" to the script tag and wrapped the src/href setters in try{}catch(e){} blocks -- maybe you can find out yourself why ;)
     
     
6. @masa141421356 solved it twice (2011-11-29) #bypass fixed
   • His way of approaching the challenge was using the language attribute trick that has been used successfully in XSSMe2. By injecting code that contained an image, a language attribute set to vbs and an event handler executing actual VBScript, the protective script was bypassed on all tested Internet Explorer versions. Different script engine -- different scope.
     
     As we learned from XSSMe2, all that had to be done to fix this bypass was assigning an empty string to any element's language attribute. After that, no inline script can be executed without further trickery. Developers should be very careful when picking the attributes they want to allow. Sometimes the harmless ones can cause more trouble than one might think.
     
     His second bypass attacked the regular expression for href attributes and allowed injecting arbitrary domains. Unfortunately, passing arguments into the RegExp object does not esacpe the dot properly -- and still has it act as a wildcard character. The fix was to escape the dot manually - very nice find!