4

I noticed that a particular page that is served over HTTPS gets an insecure content warning in both Chrome and Firefox. This seems to be because the page has an anchor with an href property pointing at a plain HTTP site.

Why is it a problem? What kind of exploit can be performed in that situation?

  • 2
    Are you sure no other resources on the page are plain HTTP? I don't think that anchors alone cause this. – SilverlightFox Jun 11 '15 at 15:16
  • 1
    For example, I do not see any warnings on ondras.github.io/rot.js/hp, even though it links to http://doryen.eptalys.net/libtcod/. – apsillers Jun 11 '15 at 15:58
  • 4
    I'm voting to close this question as off-topic because it is predicated on a mixed-content warning appearing under circumstances that do not appear to produce a mixed-content warning in practice. (Please add more information and/or an example that reproduces the warning. It is entirely possibly that links do produce mixed-content warnings, but only under specific circumstances. Without such information, this question cannot be answered.) – apsillers Jun 11 '15 at 16:01
  • 1
    This is the specific page where I found the issue: secure.myshopper.oldmutual.co.za/shopper/FundEdit The warning is being shown in the same paragraph where the browser warns about the use of obsolete cryptography – Joon Jun 12 '15 at 11:54
  • 1
    @Joon Looking at the browser console (F12) for that page, I see a warning about an insecure image, not a link: Mixed Content: The page at 'https://secure.myshopper.oldmutual.co.za/shopper/FundEdit' was loaded over HTTPS, but requested an insecure image 'http://image.providesupport.com/online-presence-image/omtfsa?t=...'. This content should also be served over HTTPS. – apsillers Jun 15 '15 at 13:30
3

Mixed-content warnings occur when an HTTPS page requests the loading of a resource over HTTP. This is dangerous because the insecure resources are vulnerable to alteration by an active attacker or eavesdropping by a passive attacker, which violates the user's expectation of security for an HTTPS page.

An anchor <a> link does not cause any resource to be fetched1, so it could not possibly cause a resource to be loaded insecurely. The situation you have described is not possible.

  • 1 If a browser prefetches pages to improve load times, is possible that a browser could choose to prefetch a linked HTTP page based on an <a> link on an HTTPS page. However, since prefetching is purely an optional optimization, the sensible behavior is for the browser to omit the prefetch for that resource, not to emit a warning about the security implications of an optimization that is technically unnecessary.
3

If the linked resource is an image or a script, often the main concern is not that an attacker could read it, but that an attacker could hijack the request and inject a modified version of the resource to change the look or behavior of the page - scripts especially, as they could be modified to do something malicious like redirecting the user to another website or stealing data the user enters into the page.

(As a somewhat unrelated side note, I personally disagree with the way many browsers handle displaying these warnings. A partially encrypted connection is still an improvement over no encryption at all, but the way some browsers show prominent warnings makes it look "worse" than an unsecured HTTP page. I prefer Safari's way of doing it, which shows "https://" but no lock icon on these pages)

  • Chrome shows a lock icon with a yellow warning triangle over it for unsecured images/stylesheets. Unsecured scripts get automatically blocked unless you explicitly allow them, in which case Chrome displays the page normally but crosses out the "https" in the URL with a red line. Seems like pretty reasonable behavior to me. – Ajedi32 Jun 17 '15 at 18:19
-1

HTTPS secures your connection to the server. The content you transfer over the HTTPS is encrypted. On the other hand HTTP is plaint text, which means the content you transfer over HTTP is not encrypted.

Now if someone is sniffing your traffic, then in case of HTTPS the attacker can only see the encrypted data, but in case of HTTP the attacker can see the plain text data.

This is the reason why HTTP is warned as a insecure content. Because as soon as you click on a HTTP link that particular link will be using HTTP instead of HTTPS. And if the user has ignored this he/she might transfer some sensitive content like password over the HTTP. The user might be mistaken by the fact that he/she was surfing a HTTPS page and all the links will be using HTTPS.

  • I am talking specifically about the anchor tag href property. All that an anchor will do is to issue a GET request to the now non-secure page. How is that a security risk? What secret information could be compromised by that? – Joon Jun 11 '15 at 13:47
  • 1
    Having a regular hyperlink (the kind that users can click) to a plain HTTP page on a secure page typically will NOT generate a warning. But references to unsecured images and scripts will, because the browser needs to fetch them in order to render the page. – tlng05 Jun 11 '15 at 14:36
  • How is that a security risk? Please read my answer again. The word content in my answers means text, image, script and all other stuff that is transferred between the 2 machines. What secret information could be compromised by that? What ever secret information you send. Now, what means secret to you, you can list all things yourself. – ρss Jun 11 '15 at 14:42
  • @pss I suspect the downvote isn't because your answer is wrong, but rather that it's not very specific; you answered a rather specific question (about hrefs) with a rather general answer (high level "HTTP vs HTTPS"). – Mike Ounsworth Jun 11 '15 at 14:50
  • 1
    @MikeOunsworth I don't hate downvotes because they let me know that I have missed something in my answer. But I personally think it is more logical if someone could take some time to comment the reason for the downvote. ;) I usually do so. I think in this way we can learn more. – ρss Jun 11 '15 at 14:54

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.