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?

  • 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 1: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 5: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

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.

| improve this answer | |
  • 2
    Thanks. Yes that was exactly what I meant: navigate directly to the view-source prefixed URL. – tohster Mar 29 '15 at 16:57
  • 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? – 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
  • 2
    @Joseph: Can confirm: i.stack.imgur.com/ygExH.png – bwDraco Mar 30 '15 at 5:19

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.

| improve this answer | |
  • 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

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.