29

Let's say there's a URL www.badjs.com which is untrusted and may contain bad scripts.

Intuitively, a view-source navigation to that URL does not execute any scripts so it should be safe. It would at least allow me to inspect the source safely.

But intuition is a terrible way to draw conclusions on security issues, so my question is:

Is view-source a safe way to look at a website from a js script injection perspective?

kalina
  • 3,354
  • 5
  • 20
  • 36
tohster
  • 413
  • 5
  • 6
  • 10
    Could you please avoid using mobile links? If you use the desktop url mobiles will (almost surely) be redirected to the mobile page anyway, and in this way you let desktop user see the page designed for them. – Bakuriu Mar 29 '15 at 20:18
  • 1
    @Bakuriu the url was composed on a mobile device and form factor has no relation to the substantive content anyway? Mobile is 32% of browser traffic these days, so the odds that a question composed or read with a mobile device is `1 - 0.68^2` or 54% and rising every month, so I don't see a need to do something unusual for desktops. – tohster Mar 30 '15 at 01:57
  • 23
    @tohster Because Wikipedia will detect that someone on a mobile device is on a mobile device, and serve them the mobile page whether or not you use the mobile link. In contrast, Wikipedia will not detect that a desktop user is on a desktop device if you use the mobile link. `m.wikipedia.org` has a very bad UI on desktop, so a mobile link is bad for 68% of traffic, while a desktop link is bad for ~0% of traffic. I've edited it to use a desktop link; you can roll it back if you disagree, but please don't (this is a bit of a pet peeve of mine as well). – cpast Mar 30 '15 at 05:24
  • 3
    Just as bugs in the JS implementation might be vulnerable to attacks, so too might the source renderer, syntax highlighter, etc. Of course, the attack surface is smaller, but it's still larger than wget or curl, and even those might have vulnerabilities. – Max Mar 30 '15 at 13:58
  • 1
    alternatively, you can do `curl http://url.ext` from the terminal, but some websites might not serve proper markup to non-browser user-agents, so you will have to spoof your UA with `curl -A "user-agent-here" http://url`. – user3459110 Mar 30 '15 at 18:42

3 Answers3

34

Yes, it is absolutely safe (in Google Chrome) to open an untrusted website in view-source mode. The key point to note here is that you should "open" the page in view-source mode, meaning you should not allow any rendering to happen by normally loading the webpage first and then viewing the source.

An example in Google Chrome would be view-source:http://www.badjs.com/

By design, Google Chrome will initiate a new GET request to the server and provide the client browser with the unrendered version of the webpage when in view-source mode.

You could also use a No-Script extension or add-on for your specific browser to prevent any scripting attacks.

Pavin Joseph
  • 706
  • 7
  • 10
  • 2
    Thanks. Yes that was exactly what I meant: navigate directly to the `view-source` prefixed URL. – tohster Mar 29 '15 at 16:57
  • 1
    Edited the answer for more clarity. I cannot speak for other browsers though. – Pavin Joseph Mar 29 '15 at 17:11
  • 2
    `view-source` works for me in Firefox 36, too. – Federico Poloni Mar 29 '15 at 19:34
  • 2
    Yes its working in Firefox 36, but not in IE 11. Firefox does not seem to initiate a new GET request when viewing source after it has rendered the webpage. Could someone who knows the internal workings of Firefox please corroborate that it is infact safe to directly use `view-source` in Firefox 36? – Pavin Joseph Mar 29 '15 at 20:15
  • 4
    Since you cannot speak for other browsers, I would not say "it is absolutely safe". And, IIRC, long ago I saw some browsers show HTML source of the page *after* JavaScript modified it. – jamesdlin Mar 29 '15 at 20:27
  • @jamesdlin Edited the answer for even more clarity. Firefox shows the modified source after it has rendered the page since it does not initiate a new GET request to the server. I hope someone could corroborate that is not the case when directly using `view-source` from the address bar in Firefox 36 – Pavin Joseph Mar 29 '15 at 20:34
  • 1
    Also, "NoScript" is not guaranteed to prevent any scripting attacks. It's another piece of software; it has bugs. There may be exploits that target a bug in the browser, a bug in NoScript, or a combination to execute scripts without permission. – Snowbody Mar 30 '15 at 05:07
  • 2
    @Joseph: Can confirm: http://i.stack.imgur.com/ygExH.png – bwDraco Mar 30 '15 at 05:19
  • 2
    Sending a new GET request of course means the server could change the script between the two requests. So you can't know for sure if what you are seeing is what you will be running. – kasperd Mar 30 '15 at 08:30
  • @Joseph @DragonLord Firefox loads the page from cache if it exists - but this is **not** the same as the rendered version. The only way to view the rendered version is through the HTML inspector. Tested by removing the body element from this page via JS and then navigating to this page by `view-source:` on a different tab, where said element was clearly still there. Actually, the context menu source browser doesn't show the rendered version either. – Bob Mar 30 '15 at 13:23
  • The browser will still redirect you if the response contains a `Location:` header, although you do still remain in "view-source" mode (tested Chrome). – MrWhite Mar 30 '15 at 18:49
22

While it is currently safe on Chrome you should not base your future checks on that. Things may change anytime and I have not seen the lack of rendering as being a specifically documented feature.

If you want to look at the code, it is much better to download the page via a command-line tool (curl for instance) and analyze what was loaded and saved in a file. This also has the added value of easily testing various pages which may be possibly served in response to different User-Agents.

WoJ
  • 8,957
  • 2
  • 32
  • 51
  • 2
    Of course, there is no guarantee of absense of bugs, so even curl might be unsafe for non-js reasons. – Filip Haglund Mar 30 '15 at 15:13
  • 4
    @FilipHaglund: this is not a matter of bugs: one day Google may decide that it will render the source in the `view-source` page (to make it dynamic, nicer, whatever). By downloading the page with a command-line downloader like `curl` you just issue a `GET` and save what is returned by the server in a file. There is no processing done because the job of `curl` is not to process anything (it is designed for that). You may have bugs in the implementation and have problems with some pages, but not security ones (as the attacks happen in whatever renders the page). – WoJ Mar 30 '15 at 17:33
0

While there is nothing wrong with the other answers saying it is currently safe, there is a potential misunderstanding going on. You said you wanted to use it to check if a site is safe, so presumably you will load a page normally after you have found no malicious content when viewing the source. If this is true, then you must be aware that websites are able to detect (or at least infer) that you are using view-source:. Not only does it, on Firefox at least, not use the cache, resulting in it loading the page a second time, but it does not load other resources. If a site sees someone with a regular browser user agent connect but load no other resources, they can infer that the user is checking the source. It is simple to automate this detection and only serve malicious JavaScript from a resource in the case that it is loaded along with all the rest of the page. This would hide its presence from your inspection of the source, despite the website still serving malicious JavaScript to you.

A potential solution would be to use Inspect Element, which looks at the currently open page and allows for reading the source. This is much harder to detect (though not impossible, since CSS can determine the size of the browser window, which shrinks by a specific amount when inspect element is open). Inspect Element is more complex, and may be more exploitable than view-source:, so you must apply threat modeling in this situation.

forest
  • 64,616
  • 20
  • 206
  • 257