Paid Advertising
web application security lab

Internet Explorer 8 and NoScript View Source Bugs

So I’ve been sitting on two semi boring view source bugs. Not because I was saving them for a rainy day or anything, but it took me a while to think through them properly. Let’s pretend someone who is not entirely clever wants to do forensics on something to be sure the page is doing what they expect it to. This would be something like making sure that the username and password inputs are being posted to the proper SSL enabled website or something. We wouldn’t want that to be subverted so we view source to make sure it’s all kosher. Here come the two bugs.

The first bug is in Internet Explorer 8. Internet Explorer has a typical null byte bug that makes it truncate the new view source function upon reaching a null byte. So if you were to go to a page that had a null byte in the middle of it, the rest of the page wouldn’t pop up. This is not true if you use an external editor or their new nifty Developer Tools functionality, but not many people do either of those. This doesn’t appear to affect any other Internet Explorer version that I looked at.

Next is a bug in NoScript for Firefox. If you enable JavaScript (imagine it’s a site you trust or are forced to enable for various functionality) and POST some data from one page to another and then view source you’ll notice that instead of it sending a POST request it sends a GET request. I have no idea why, but it can be detected and in the case of seeing a GET request on a page that requires a POST the page can modify it’s resultant source code.

Both of these bugs I find to be fairly minor, but it’s just another reason you can’t trust browsers to present you with all the facts of the situation unless you really know what you’re doing. There’s a demo of the code here if you want to test it yourself (again, only works in IE8.0 or in Firefox with NoScript enabled). In either case you must enable JavaScript for it to work. If I don’t post before then and you celebrate it, Happy Easter!

7 Responses to “Internet Explorer 8 and NoScript View Source Bugs”

  1. ChosenOne Says:

    FYI: if NoScript is set to allow javascript generally (sorry don’t know the correct term, my NoScript version is localized), the bug does not occur and your alert() is visible.

    Happy Easter to you too.

  2. Giorgio Maone Says:

    The NoScript one was known, but I had other priorities to cope with (as you said, this is a very minor annoyance).
    view-source: URLs are collectively considered untrusted by NoScript for obvious reasons. Now, when Firefox tries to show you the source of a page which is not stored in its cache (like the result of a POST) it appears (to the observers of its networking workflow, like NoScript) to send a request originated from “view-source:” and targeted to actual the page URL (don’t ask me why, it’s a Gecko implementation detail).
    POST requests from untrusted sources to trusted targets, as you surely know, are turned into idempotent data-less GET requests by NoScript as a minimalist anti-CSRF countermeasure, waiting for ABE.
    Anyway the fix is quite easy, and I’ll roll it up with next dev build or next release at most, if you can wait one week ;)

  3. Giorgio Maone Says:

    Fixed in NoScript beta,

  4. Eagleal Says:

    However, I can see the script trough Firebug, Net -> POST view-source.cgi

    After the tag:

    alert(”Pretend I’m a peice of malicious code - Now find me…”);

  5. RSnake Says:

    @Giorgio - thanks for the quick fix! Works like a charm. This will make testing less erroneous, for sure!

  6. rvdh Says:

    I reported the view source bugs last year to Microsoft, although mine was using UTF-16 encoding to hide all the source. In a meta tag, or header, or simply save the file as UTF-16 and the source will be invisible to the Unicode parser. Looks like they didn’t fix it yet.

  7. tv Says:

    Looks like it affects Chrome as well unless you “Inspect element” instead of “View page source”.