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

Improve this question
1

6 Answers 6

Reset to default
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.

Improve this answer
7
  • 5
    +1 for pointing out the importance of server authentication, which is often forgotten as a benefit of SSL.
    – AviD ♦
    Nov 30, 2010 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 2, 2016 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, 2016 at 6: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, 2016 at 6: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 4, 2020 at 8:48
17

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.

Improve this answer
0
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.

Improve this answer
1
  • This hijack will only work on the assumption that the frame content is (genuine) server data.
    – Zimba
    Dec 4, 2020 at 8: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.

Improve this answer
1
  • This would only work if users on client systems actually check that the certificate matches the url presented.
    – Zimba
    Dec 4, 2020 at 8: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.

Improve this answer
3
  • 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 4, 2011 at 5:17
  • Cookies are not shared between http and https
    – Timo Huovinen
    Aug 1, 2018 at 7: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 4, 2020 at 9: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.

Improve this answer
1
  • No it's not; https sites don't prevent MiM attacks
    – Zimba
    Dec 4, 2020 at 9:23

You must log in to answer this question.

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