51

I've seen websites placing HTTPS iframes on HTTP pages.

Are there any security concerns with this? Is it secure to transmit private information like credit card details in such a scheme (where the information is only placed on the HTTPS iframe form, and not on the HTTP parent page)?

Scott Pack
  • 15,167
  • 5
  • 61
  • 91
Yahel
  • 613
  • 1
  • 5
  • 6

6 Answers6

50

If only the iframe is https, the user cannot trivially see the URL it points to. Therefore, the source http page could be altered to point the iframe anywhere it wanted to. That's pretty much a game-over vulnerability that eliminates the advantages of https.

user502
  • 3,261
  • 1
  • 22
  • 18
  • 5
    +1 for pointing out the importance of *server authentication*, which is often forgotten as a benefit of SSL. – AviD Nov 30 '10 at 19:14
  • 1
    I recognize this is an old question, but was hoping someone might explain how having HTTPS in the origin page resolves an issue of a rogue script changing the location of the iframe? If the origin page is HTTPS, you could still have a rogue script changing the iframe destination, no? – Matt James May 02 '16 at 18:08
  • @MattJames, if the origin page is also HTTPS, then it cannot be changed in transit unless the MitM has a valid certificate for the domain (which shouldn't happen unless the CAs aren't doing their jobs). They can however still intercept the original HTTP -> HTTPS load and redirect it to a domain under their control. Users would be able to detect this by looking at the URL and the certificate, both of which are shown only for the topmost frame. Having said that, most users probably wouldn't actually notice, which is one reason why accounts do get compromised sometimes. – Miral Jul 23 '16 at 06:14
  • The assumption of course is that the attacker is sitting in the network. If they can modify the source page on the server to include rogue code, then all bets are off. Similarly if they can get a script that can alter page content installed into the user's browser, then they're similarly vulnerable. (So people using Greasemonkey/Tampermonkey/etc need to beware, though again many don't.) – Miral Jul 23 '16 at 06:20
  • @Miral: even if MitM "intercept the original HTTP -> HTTPS load ", they won't be able to decipher the https payload data, right? The worst they'd do is redirect all comms from client to themselves instead of the server, and make the client think the connection is with the server – Zimba Dec 04 '20 at 08:48
  • I'm not sure how you think "redirecting all comms to itself" is different from "deciphering the https payload data". HTTPS encryption prevents a third party observer (e.g. in the routing chain) from decrypting the payload. It does nothing if one of the two endpoints is compromised in a way that the other party accepts as valid. (The point of certificate validation is to restrict what is considered valid.) – Miral Dec 07 '20 at 03:27
  • And if one of the "third-parties" in the middle can successfully fake being the endpoint (by presenting a server certificate that is considered valid by the client), then this is a successful MitM attack -- neither the client nor the server can tell the difference, provided that the attacker can keep up the charade (which is easy if they're only logging and not also trying to add malicious content, but that's not hard either). The whole thing is only as good as the trust in the CAs. – Miral Dec 07 '20 at 03:35
18

iFrames will expose the inner HTTPS site to numerous javascript and cookie attacks in older browsers, and may cause issues in newer browsers.

To fix this, look up "Frame Busting" to detect if iFrames are being used. Consider this solution on StackOverflow:

https://stackoverflow.com/questions/958997/frame-buster-buster-buster-code-needed

In that code, you can detect if iFrames are being used, and offer alternative content to direct the user to the proper site.

Community
  • 1
makerofthings7
  • 50,090
  • 54
  • 250
  • 536
15

A HTTPS iframe within a page served over HTTP will not allow the user to be sure they are actually using the HTTPS connection that they expect to be; therefore, this potentially allows the iframe to be hijacked in a simple attack such as an iframe injection. This would allow password harvesting, among other things. Such an attack could begin through a Trojan, a virus, or simply visiting a malicious website.

Paul
  • 261
  • 2
  • 7
  • This hijack will only work on the assumption that the frame content is (genuine) server data. – Zimba Dec 04 '20 at 08:53
7

Yes, while most recent browsers will properly sandbox the SSL parts, you are undermining all the functionality added to browser chrome to provide user feedback regarding the contents. I for one would not provide any sensitive information without checking the URL showing in my browser.

symcbean
  • 18,278
  • 39
  • 73
  • This would only work if users on client systems actually check that the certificate matches the url presented. – Zimba Dec 04 '20 at 08:53
2

In addition to the possible hijacking scenarios already given, you may run into issues on IE6/7 if you point to either an HTTP or HTTPS page requiring login. Basically, the cookies from the iframe's page are expecting you to be using the same protocol (HTTP or HTTPS) and so if the page you're putting the iframe on is using HTTP instead of HTTPS, it would prevent the user from being able to log in.

Dominique
  • 129
  • 2
  • 2
    this answer seems jumbled. I'm not sure what you are trying to say, or what problem you are alluding to. – D.W. Jun 04 '11 at 05:17
  • Cookies are not shared between http and https – Timo Huovinen Aug 01 '18 at 07:54
  • are you saying the browser would check the parent frame of the one serving the cookies or check all the frames? Or are you referring to secure cookies? – Zimba Dec 04 '20 at 09:20
0

Any http request means two things: One, hackers might be snooping and reading both the request and the response. Two, hackers might be able to return a different website from the original one.

So if I access your website through http, and receive an https link back, hackers might learn about that https link, but all in all it's not less secure than an http link.

However, there is no guarantee at all that I received your website and not one provided by a hacker. So that https frame might not even be present on the correct site, only on the hacked one. And there's no guarantee at all where it points, therefore no security at all.

Once you start with http, as far as security is concerned, it's game over.

gnasher729
  • 1,823
  • 10
  • 14
  • No it's not; https sites don't prevent [MiM attacks](https://www.quora.com/If-a-professional-hacker-can-hack-https-websites-then-why-are-the-websites-moving-for-https-instead-of-http-for-security) – Zimba Dec 04 '20 at 09:23