18

I'm dealing with a phpBB forum user who wants to set up SSL on their entire site to secure user credentials and "private" parts of the website.

However, they want to preserve the traditional forum user experience of user generated img tags to offsite content, which triggers a browser mixed content warning. The only solution we've come up with is an SSL granting proxy. After pondering the problem for a while now, I'm curious why do browsers warn specifically about images? I understand the case for javascript, but images?

curiousguy
  • 5,028
  • 3
  • 25
  • 27
jldugger
  • 283
  • 2
  • 6

5 Answers5

17

I would assume your reasoning is something like, "If the person constructing the page chose to send some of its images insecurely, then the browser should respect that this decision was done for a reason and allow it without a warning. The page is as secure as the entity providing it wanted it to be."

By contrast, the reasoning of the browser developers is something like, "We are putting a secure icon on the page as seen by the user and the user should be able to assume that means the whole page is secure. If some part of it isn't, the user deserves to know that."

Both arguments are valid, they're just different interpretations of what it means for a web page to be secure.

There are specific risks with images too. The image is requested in the clear using the HTTP protocol. This discloses any information in the URL or headers. The most serious threat is that the image could contain instructions or information that the user would assume securely originated from the site the user chose. This could be used for phishing attacks.

David Schwartz
  • 4,203
  • 24
  • 21
  • So is there any particular security argument against using the proxy linked in the question? – jldugger Jul 14 '12 at 20:12
  • 1
    @jldugger: Only that in a sense you're "vouching" for the content you proxy by providing it to the user on a secure page. So one could make an argument that you have an obligation to ensure it's safe. (Or warn the user.) – David Schwartz Jul 15 '12 at 01:41
  • Thanks, @DavidSchwartz, makes sense! I'm deleting my earlier comments now. – D.W. Jul 15 '12 at 23:52
  • @DavidSchwartz "_Also, for a typical forum, an untrusted person can choose and control the URL and can use it to gain information they're, arguably, not entitled to._" In a forum, messages and their content are untrusted user content by definition. I don't understand which specific threat exists with `http:` images in a forum accesses over `https:`. – curiousguy Jul 16 '12 at 03:23
  • @DavidSchwartz "_So one could make an argument that you have an obligation to ensure it's safe._" as in "safe for all the family", or "safe for your computer"? – curiousguy Jul 16 '12 at 03:24
  • @curiousguy: 1) If the content is untrusted, they why should it display on a page with a security icon? The point of the secure icon is to say that you can trust the content. 2) That's context dependent. For example, if you go to a secure page and it says you need to click on a link and change your password, you should be able to trust that you should click on that link to change your password. User-generated content that can show an image that tells you to do things and user-controlled links off site mean the page shouldn't be trusted. The browser shouldn't tell the user they can trust it. – David Schwartz Jul 16 '12 at 06:37
  • In this case, the security icon has nothing to do with "trusted content". The icon indicates content transmitted securely from the server: all the content (all the HTTP resources) has been obtained via **(one or more) trusted connexions** with the **(one or more) servers**. Context indicates to the user if the content is "trusted"; in a forum, context tells the reader that the message, including images, is not more trusted than the person with the given pseudonym who submitted such content - and here it does not matter if the images were transmitted via a secure transport. – curiousguy Jul 16 '12 at 07:04
  • Which threat is the broken lock icon supposed to protect against? (assuming the user notices this tiny UI change) – curiousguy Jul 16 '12 at 07:13
  • @curiousguy: The problem with your argument is that it applies to this one specific context. That's why you say things like "and here it does not matter". The design of the browser is not specific to this context. And there are cases where it does matter. – David Schwartz Jul 16 '12 at 07:27
  • @curiousguy: A phishing attack embedded in one of the images, made to look like the web page's normal text. (And it's usually not just a broken lock icon but a warning pop up as well.) – David Schwartz Jul 17 '12 at 10:49
  • @DavidSchwartz "_A phishing attack embedded in one of the images_" so maybe the web-browser should only show the broken lock if there is a *large* `http:` image? ;) – curiousguy Jul 18 '12 at 01:24
11

The browser doesn't know what type of information an image or other resource is supposed to convey: perhaps it's just a logo, or perhaps it's some piece of UI, or perhaps the image is the whole point of the page you're visiting. There's no way for the browser to know whether a resource is important or not to the user.

When the primary (page) URL is loaded with HTTPS, then the browser signals to the user that the page being viewed is secure, usually with a lock icon, or green URL bar, or something like that. It doesn't say, "this page is secure except for that one image there" -- there simply isn't a mechanism to indicate to the viewer which parts are the insecure parts. So instead the resolution is that if the browser says that the page is secure, then ALL elements on the page must be secure, or the user has to be notified of the exception.

Note that viewing an insecure URL with a few secure elements generates no notifications or warnings, but at the same time there is no signaling to the user that there is any measure of security on the page. Since there is no expectation of security, the presence of mixed content is not noteworthy.

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • "_there simply isn't a mechanism to indicate to the viewer which parts are the insecure parts._" which is a problem, because there are mixed-content pages, and the user might get used to the warning and disregard it. – curiousguy Jul 18 '12 at 03:53
6

Short answer: lack of semantic information

Long answer

In a forum, the user naturally expects stuff to come from "unauthorised" third parties (any registered user, could be anyone really), not only from the webmaster (and authorised authors).

The user fully understands that messages do not represent the webmaster opinion, and are not "authorised" in any way by the owner of the domain. For any reasonable user, there is no strong particular expectation regarding the content of messages appearing in the web-page, or for images included in such messages (there is a weak expectation that scum is removed on a timely basis, but before it is removed it can be seen by anyone).

But a web-browser does not understand what a forum is. The https://example.com/ page is expected to be trusted to come from example.com and to securely (as in transport security) represent example.com web-master opinion, and any big enough insecure image (in particular IMG without an explicit size) could be used to show a big warning that

Your account is suspended. You must go to http://fakesite-example.com/ to confirm it. If you don't, your account may be permanently deleted.

rendered as an image.

Of course, in a forum message it would be taken as representing the post author opinion by the user, but the web-browser cannot know that.

curiousguy
  • 5,028
  • 3
  • 25
  • 27
3

Actually, tylerl, the browser does know what type of information a resource is intended to convey.

The obvious risk is that information is exposed in the request (once javascript is injected into the page, it's trivial to inject data into the URL without changing the functionality, e.g. img.src=img.src+'?session=1234'; ) and it can therefore be used for compromising the exchange.

Another risk is that the image may have value - in terms of copyright, confidentiality or perhaps as part of an authentication process.

symcbean
  • 18,278
  • 39
  • 73
  • I should also have added that, with the addition of canvas support in html5, content delivered as an image now contains machine readable data. – symcbean Jul 13 '12 at 08:43
  • Is any of that scheme dependent? – curiousguy Jul 16 '12 at 03:27
  • Eh? Yes, no. SSL is usually only available as an option on HTTP - you can't make JSON requests over FTP:, telnet:. Any data sent over an unencrypted protocol is by definition not encrypted. – symcbean Jul 16 '12 at 09:15
  • hold on though -- if I'm able to inject javascript into the page, I can do evil without triggering a mixed content warning. consider I create a NEW image, add it to the document with no display (or outside the page, whatever) and add the session ID or whatever other params/cookie values/etc I want. If the NEW image is loaded from a server I control with HTTPS and a valid cert, then there is no mixed-content, but I've still done evil. I also don't see how a mixed-content warning applies to copyright/confidentiality? – Kasapo May 09 '17 at 19:08
1

Another reason why warning about mixed content is a good idea is that a MITM can replace an "insecure" image with one that exploits an RCE (remote code execution) vulnerability in the user's browser.

Here's an example of such vulnerability: https://nvd.nist.gov/vuln/detail/CVE-2017-2416 --basically you can serve a crafted image containing executable code and have that code executed on older versions of macOS and iOS.

So even though I believe that passive content is generally more secure than active one (but unfortunately I don't know any papers to back this "belief"), any content that can be arbitrarily replaced by a MITM is a potential security threat.

Tomasz Zieliński
  • 191
  • 3