Paid Advertising
web application security lab

Microsoft Engineers are Paying Attention

Hallelujah! It’s been a great past few days, and I couldn’t even tell you all until now. I’ve been exchanging emails from David Ross from Microsoft for a few days regarding some anti-XSS stuff he’s working on. That MS is reading and listening gives me a great deal of hope! Further, David forwarded me an excerpt from an internal paper he had written (the snippet comes from a paper that expresses David’s own individual views as a security researcher and not necessarily the overall views of Microsoft). Take a look at the snippets:

RSnake’s “XSS Cheat Sheet” provides a long list of techniques such as the STYLE/expression trick described above. This is a great resource that can be leveraged by web application penetration testers looking for ways to circumvent potential fixes. But the cheat sheet effectively also provides a great reference of obscure techniques that enable XSS where it might not otherwise be possible.


The one significant XSS-focused attack surface reduction measure implemented for Internet Explorer 7 was actually not intended to block XSS. In an effort to reduce non-XSS vulnerabilities involving the use of “javascript:” URLs, a mitigation was put in place that disables these URLs for navigation. The use of javascript: URLs in unusual places (such as IMG or EMBED tags) often enables XSS where it would not otherwise be possible. The mitigation effectively disabled these usage scenarios and has proven to be an effective XSS-focused attack surface reduction measure, albeit inadvertently.

As a side note, that jives with what other Microsoft higher ups have told me about the reason for that change (although it was pretty unofficial and at first they told me it might be a bug, so it’s nice to get some clarity on that change). I’m glad to see it recognized as to how that change came to be. It’s nice to see that internally it is realized how it impacted the number of vectors that affected Microsoft Internet Explorer from version 6.0 to 7.0.

Incidentally, RSnake took note. In an October 14 posting to his blog,

RSnake states:

“I’m glad the JavaScript directive has been relegated to IFRAMEs and HREFs rather than being possible anywhere a location was - thereby definitely reducing the attack surface for the newest browser from Microsoft.”

Until a few days ago I had had very little hopes for the browser companies stepping up to the plate and coming up with the solutions for the problem. It appears that we are developing new security issues at a rate much faster than the browser companies are fixing them. They have the most to gain by fixing these issues too It’s really nice to be talking to people who can make a difference and are committed to it. David and I are now working on some concepts for more browser security. Obviously all of this would be a ways away or may never happen, but at least I now have some hope. What a great story - browser company teams up with independent security researchers to come up with cutting edge solutions. “Teams” might be a strong word, but it’s as close as I’ve seen the browser companies come to walking hand in hand with the security community and I’m glad to be a part of it. I just can’t wait to get started.

Don’t worry, I’m still going to be as dispassionate about browser religion as I’ve ever been (as you may or may not remember, I’m the one who came up with the concept of content-restrictions in Firefox). I like to stay objective. I’m just eager to get the percentage of effective browser exploitation down to where it can be mitigated through whatever means are available, and right now Microsoft is really listening.

And no, telneting to port 80 just isn’t an option. ;)

9 Responses to “Microsoft Engineers are Paying Attention”

  1. ThePost Says:

    Nice one RSnake, well done you!

  2. Jungsonn Says:

    Great work! finally some sense!

  3. camera Says:

    I was just reading that content-restriction post .. wouldn’t it be a good idea to just have a meta-tag in the HEAD section that says “no javascript on this page should be executed except for external/linked scripts in this HEAD section” ?
    this would tie in perfectly with the concept of separation of content/layout AND behaviour, which uses only scripts linked with SCRIPT SRC= in the HEAD section, and targets HTML elements only with “hooks” on their ID-attributes.
    no more intertwined JS and content, is good for both security and standards/accessibility points of view, i’d say?

  4. RSnake Says:

    Meta was something we considered as a secondary fall back point in the code that we would allow. The problem with that is that attackers often have access to the head of a document (inside JavaScript, inside head tags, inside Meta when talking about charsets). So it’s really far less reliable than you’d think to limit JavaScript to the head of a document only. But yes, we definitely did think of that and planned to build it in as a secondary and less recommended feature.

  5. camera Says:

    > The problem with that is that attackers often have access to
    > the head of a document (inside JavaScript, inside head tags,
    > inside Meta when talking about charsets).

    I don’t quite understand what you mean, could you give an example?

    assuming that user-input is only echoed back to the browser in the BODY section (which is not that hard to ensure, right?), how would an attacker gain access to the HEAD section that says “only javascript in this section will be executed” ?

  6. RSnake Says:

    There are tons of examples where administrators allow user submitted content to be echoed back in the title tag for instance. But yes, if you could ensure that no text was ever outputted above the body, you should be okay.

  7. maluc Says:

    i think it’s a useful addition, but nothing that can be relied upon. and in the case of different companies working together, it can really complicate matters without much gain. (for example, everyone that shows google ads on their site - it adds scripts in the body)

    it still does nothing to prevent injecting iframes or CSS hacks (-moz-binding and xx:expression) that execute javascript or any events like onload. So i don’t believe it will be as effective as you’d hope.

  8. zeno Says:

    When I was working on my RSS Vulnerability research I discovered IE 7 beta was affected and contacted microsoft. They replied back with ‘Try beta 2 it came out yesterday we added some security features’. I downloaded and tested out IE7 and sure enough they locked it down to the point where my RSS based attack ceased to work. I also can say that Microsoft is starting to pay attention and implement fixes before issues are discovered.

    - zeno [RSS Feed]

  9. Talha Says:

    nice one snake