0

Per current security recommendations & browser support, is it okay to have an https iframe in an otherwise http-only set of pages?

Is this not a dupe? It is, but I want current trends because when I tested a few months back browsers warned me about mixed content, but now when I do an iframe of a secure login page overlay from my own domain I don't get any warning. (URL is a.com but it points to my own local host, main url us http://a.com/, which has an iframe that comes from https://a.com/login)

I presume it's because https is not at fault and it was JavaScript that led to the vulnerabilities and now that is fixed?

Tested in FF 31, Chrome 36, IE 9

I did see:

I understood that the risk is that the user could have an addon/malicious program that changes the iframe's source. If the user's computer is so badly compromised aren't all bets off anyway?

Should we tell our client, even in 2014, no https login iframe? If the user wants to login, refresh page to the https version or redirect the user to other login page and post login can come back to http in safe areas (non checkout and account related).

I know it's not much of a computational thing but for some reason the client is fixed on the idea that some pages are better http or https (default http though user can change to ssl manually)

Community
  • 1
tgkprog
  • 109
  • 10
  • 3
    There is risk of the iframe URL being changed anywhere on the network since plain text, the client doesn't need to be compromised. – David Houde Aug 26 '14 at 14:50

2 Answers2

2

https login iframes are secure from passive eavesdropping but won't help against active MITM.

The js vulnerabilities may have been closed, but the issue remains, as the parent html (served over http) can still be modified, including the url of the iframe. Then the MITM can set up the login page via http and that will be loaded by targeted users. Only users who are using a password manager will notice the change, as password managers treat https and http urls as different origins. This is nothing browser vendors can fix.

For example, instead of serving

<iframe src="https://site.example/login.php" name="login_frame">

the MITM attacker can serve

<iframe src="http://site.example/login.php" name="login_frame">

and serve a intercepted login page on the http page.

And javascript, as described in the original anwser, can still access the iframe attributes. Try it yourself: http://jsfiddle.net/eLqn0ky9/

Community
  • 1
user10008
  • 4,315
  • 21
  • 33
1

As far as I know, iframe are always vulnerable to Clickjacking.

This is a big reason why website should not do log in in an iframe and why you need the header X-Frame-Options or now frame-ancestors on your log in page.

Also, as mentioned in your post and that answer, the content of the http page can be intercepted and changed by a man in the middle. Since the MitM can change the url of the iframe, you are now vulnerable to phishing attack.

Community
  • 1
Gudradain
  • 6,921
  • 2
  • 26
  • 43