Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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 : http://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?

share|improve this question
    
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 '13 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 '13 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 '13 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-fir‌​efox-23/ –  nedR Oct 4 '13 at 10:41
add comment

3 Answers 3

up vote 2 down vote accepted

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).

share|improve this answer
    
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 '13 at 17:48
add comment

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.

share|improve this answer
    
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 '13 at 14:47
add comment

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.

share|improve this answer
    
That's a concern with cookies lacking the secure flag. Mixed content doesn't have much effect on this. –  CodesInChaos Jun 26 '13 at 9:59
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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