10

What are the potential vulnerabilities that might arise if a webpage is only partially encrypted.

I can think of 2 possibilities:

  1. You can change the non-encrypted parts of the page (HTML, CSS, Images, JS) through a MITM attack to partially change the look of the page.

  2. You could inject malicious JS through the insecure connection in order to steal/modify the encrypted parts of the page thus rendering the entire connection insecure.

Is the 2nd scenario possible or do web browsers incorporate some security mechanisms to prevent it from happening?

This question also has implications with regards to the Stack Exchange n/w, since only the iframe containing the login form inside the login page is encrypted : https://meta.stackexchange.com/questions/96004/login-to-stack-exchange-account-doesnt-use-https-ssl

Update:

As @Ladada pointed out, this question is actually broken into multiple parts:

Case 1: An insecure page loading a secure iframe to transmit confidential data

Answer: As davidwebster48 pointed out in his answer, this mechanism is trivially defeated since the insecure parent page can be manipulated to load the iframe with a different page of the attacker's liking. As a side note, this means that StackExchange's login system is vulnerable to MITM attacks despite using https login forms.

Case 2: A secure page loading an insecure page via an iframe

(Assuming no confidential data is handled by the insecure iframe). This case is particularly interesting in that Same-Origin policies also come into the equation. Even if both pages may be from the same domain, since they both use different protocols, (one HTTPS and the other HTTP) this will cause same-origin restrictions to kick in. I am not sure whether these restrictions are enough to stop our attacker dead in his tracks.

Case 3: A secure page linking to insecure JS

My answer: I think this is obviously a fail since the attacker could modify the JS file to access/manipulate the entire page.

Case 4: A secure page linking to insecure sources like images, CSS

Could the attacker change enough of the look of the page to do a phishing attack? Or could he mount a Cross-Site Scripting attack?

Improve this question
4
  • It strongly depends on what you encrypt. Is there a good reason to only encrypt some parts? Is there so much traffic?
    – user857990
    Jun 26, 2013 at 9:27
  • There are two related issues here: Loading HTTPS elements inside a plain HTTP page and loading HTTP elements inside an HTTPS page. Good answers should cover both possibilities. It's also worth covering the difference between loading javascript, css and images over HTTP and the effect of the secure and http-only attributes to cookies.
    – Ladadadada
    Jun 26, 2013 at 10:56
  • @user857990 This is not regarding anything I am working on. I am just observing the fact that many sites out there including gmail, StackOverflow only partially encrypt their websites.
    – nedR
    Jun 26, 2013 at 13:13
  • Its good to know that firefox since version 23 is taking steps to block mixed content: https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/
    – nedR
    Oct 4, 2013 at 10:41

4 Answers 4

Reset to default
9

Let's examine each case from the perspective of an active attacker Malroy and a passive attacker Eve.

Case 1: An insecure page loading a secure iframe to transmit confidential data

Passive: You're secure against passive attacks while you use the secure iframe. However, in the case of log-in iframes, if your session token is ever sent in the clear, Eve can impersonate you. (I still count impersonation as "passive" here, since Eve is not actively tampering with your connection; she's just making her own connections with new information she learned.)

Active: If the HTML page itself is insecure, you've already totally lost. You can have every subresource on the page be securely transmitted, but it doesn't matter: Malroy has already rewritten your page to use totally different resources.

Case 2: A secure page loading an insecure page via an iframe

Passive: Obvious major problem here: anything you do in the iframe is in plain view. However, Eve can't see what you do in the top-level secure page. Still, the user is left confused about what elements on the page can be interacted with securely and which can't.

Active: Malroy can make anything appear in the iframe; I hope you weren't using it for anything important. I don't think there's any way for Malroy to break out of the iframe and read or alter your outer secure page, because browsers already assume cross-origin iframes are not trustworthy. If there were a way to break out of the iframe, I think it would be considered a serious security bug in your browser (which isn't to say those don't exist, but that's an implementation problem, not a theoretical issue with mixed content).

Case 3: A secure page linking to insecure JS

Passive: Eve can learn what HTTPS site you are viewing, based on what HTTP resources you load. (Granted, she might be able to do this over a secure connection, based on destination IP address and size/pattern of the encrypted resources you fetch. Regardless, HTTP only makes things easier for her.)

Active: As you guessed, Malroy can make your HTTPS page completely rewrite itself by feeding it an altered script.

Case 4: A secure page linking to insecure sources like images, CSS

Passive: Same as case 3, above.

Active: CSS is pretty powerful. If Malroy could rewrite a CSS resource, he could do some pretty heavy presentation manipulation. As an example, perhaps Malroy re-styles a the inputs fields of a forum's "Create New Thread" page to look like a log-in page. This tricks the user into thinking his session has timed out, and he unwitting submits his credentials as a public new post.

An active attacker could also use CSS to prompt a client to participate in a CSRF attack, e.g., by using background-image: url(http://www.bigbank.com/transfer?amt=1000000&to=malroy).

Improve this answer
2
  • Yeah. What you said seems to make perfect sense. Which means the encryption on most supposedly secure sites out there are easily defeated because of all the external scripts and resources they link to. Another reason to use NoScript- stop MITM attacks posed by case 3.
    – nedR
    Jun 26, 2013 at 17:48
  • @nedR If the page is loaded completely over HTTPS you won't need NoScript to prevent MITM.
    – Jon
    Nov 4, 2015 at 5:39
6

This page has an excellent explanation and demo: http://www.troyhunt.com/2013/06/the-security-futility-that-is-embedding.html

If you assume the attacker can change the non-encrypted parts of a page, then he will be able to change them so that they include his own malicious login form, instead of the secure login form.

Improve this answer
1
  • Thanks for the answer. I guess this means stackoverflow's login system is insecure. I have modified my question to consider other possible scenarios than the case of an insecure page hosting a secure iframe
    – nedR
    Jun 26, 2013 at 14:47
2

A possibility that pops into my mind is session high-jacking. If the session cookie for example is transfered in a non-secured manner, then this could be high-jacked.

Improve this answer
2
  • That's a concern with cookies lacking the secure flag. Mixed content doesn't have much effect on this.
    – CodesInChaos
    Jun 26, 2013 at 9:59
  • @CodesInChaos Mixed content could be used as a vector for a downgrade attack.
    – Jon
    Nov 4, 2015 at 5:40
1

A possible scenario for Case 4 is one where a MITM replaces an 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.

Of course such MITM could run the code in the context of any page, but assuming that they can't escape the sandbox, it's the mixed content issue that allows them to run code in the context of an otherwise secure page. (Http pages are insecure anyway as anyone can inject anything there and it can be JavaScript or WebAssembly.)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .