Paid Advertising
web application security lab

Running JavaScript in Chrome Despite View-Source

Yeah, I know, I’m very late to the rush of installing the way over-hyped and extremely poorly named, Chrome browser. For those who aren’t in the know, it’s sort of like naming a car “Engine”. Ignorant person says, “I’ve got an Engine.” Smart person says, “I know, I have an Engine too. Everyone who has a car does.” Ignorant person says, “Really? I thought they just came out.” Smart person says, “Wait, are you talking about the car, Engine.” Ignorant person says, “Yes, of course I am.” So people who actually know what chrome is have to deal with ignorant people that think we’re talking about Google’s attempt at installing more crap on people’s desktop and confusingly misinterpret when guys like us are talking about chrome versus Chrome. Gah!

Anyway, despite that idiocy which I am sure will haunt me for many many years to come, I was going through looking at some old functionality that I haven’t toyed with in a while and I noticed something odd almost immediately. Google Chrome appears to allow JavaScript to fire despite the fact that you are viewing source through the view-source: directive. Click here for an example (only works in Chrome with JavaScript enabled). This doesn’t work in IE, Firefox, Safari, or Opera - yup, it’s a Chrome only problem. Why is this a problem? Because some security people use view-source: to neuter the danger of pages that they think are potentially malicious - so that they can safely view the page without any JavaScript firing - alas, so much for that idea - at least in Chrome.

13 Responses to “Running JavaScript in Chrome Despite View-Source”

  1. Dan Weber Says:

    Does this also apply if I view source while normally browsing a web page?

    View source should not have side-effects. . .

  2. RSnake Says:

    Indeed it does, Dan… indeed it does. So sad.

  3. Sébastien Duquette Says:

    Ouch, this is lame.

  4. Kishor Says:

    If I load hxxp:// directly, I see the same alert twice.

  5. Metal Says:

    That reminds me of some ancient Netscape versions where your html page could “escape” from view-source mode and end up rendering images and run javascript.

    Basically, “view-source” would just escape and colorify the source and render the result in a browser page, and that escaping was somewhat botched.

    If I remember right, one of the fun things about this was that view-source: URLs were not bound to the same domain sandboxing policy as the underlying page would have been.

    That’d be one thing very worth checking about this chrome view-source issue.

  6. sirdarckcat Says:

    This is also possible on firefox with view selection source code.

    Control+E and then “View selection source”, or in webdeveloper just click: view source -> view generated source, or

    We all should use IE8 haha


  7. .mario Says:

    “Because some security people use view-source: to neuter the danger of pages that they think are potentially malicious”

    Wow. This seems to be even more ‘mentally challenged’ than the poor naming for the mentioned browser. It by the way works in later Chromium builds too (tested If you want to avoid JS switch it off or use NoScript/Lynx :) Nice find though.

    @Kishor: That’s expected behavior.

  8. RSnake Says:

    @Kishor - right, but it wasn’t the same alert - one is the JavaScript that you would want to neuter and the other alert is the one in the headers. Both should fire if you go there directly and neither should fire if you don’t.

  9. Jelmer Says:

    Or just use netcat if you dont trust any browser and respect your own privacy at all cost.

  10. Kishor Says:

    Ah, I see. Should have noticed the header earlier.

  11. Wladimir Palant Says:

    sirdarckcat: The testcase you link to is simply about document.body.cloneNode(true) executing event handlers on cloned images, that’s what “View selection source” is doing before actually viewing source. This behavior in itself is definitely correct, it’s consistent across browsers. There might be some danger due to context menu triggering it - yet I don’t see any right now. But since you attached the testcase to a bug that talks about an entirely different issue (and which is going to be resolved as INVALID from the look of it) I cannot even comment on it. Honestly, if your bug report is a confusing mess (mostly citing behavior that every web development rookie knows about but without explaining what’s the “big danger” here is) and you behave like a complete jerk, nobody will bother figuring out whether your report has any valid points in it.

    RSnake: Very nice finding! Lucky me that I use wget for sites that might be malicious. Then again, I don’t use Chrome in the first place…

  12. Eponymous Says:

    I keep a shortcut to wfetch.exe on my quick launch bar. Old but effective!

  13. Neil Says:

    Nice catch. Chrome v1 showed a lot of promise and was very fast, but the wheels have started coming off the bus since then. Nothing but half-ass fixes and freebie WebKit updates. I guess they have all their talent working on the new OS.

    How did you insert this second alert? Where does it go in the header? Sorry for the lame question - I know a lot about web development, but not so much on a hacking side. ’bout time I learned…