8

There is a website that tenants can use to pay their rent. That website uses an http address but apparently uses a third-party product, which embeds an iframe into the page. The source of that iframe is https and all forms within the page are within that iframe.

I'm wondering what are the security risks of this type of setup for the users.

I would also add that located on the bottom of every page is a "seal" from godaddy that you click on and it provides some security-related information about the iframe source.

My intuition says that is not ideal. For one thing, seeing the browser's address bar unable to provide identity/encryption information is disconcerting. Without viewing the source of the page, how do I know where the iframe content is from? Is relying on the godaddy seal sufficient?

Dave L.
  • 193
  • 7

2 Answers2

9

I'm wondering what are the security risks of this type of setup for the users.

It's almost as bad as serving everything over plain HTTP.

You get protection against purely passive listening attacks, but really anyone in the position to do that kind of man-in-the-middle attack is very likely also to be able to do an active attack, changing the content that gets sent back to the browser. That could include changing the iframe src in the unprotected parent page, or injecting some attack script.

In practice the HTTPS-iframe gets you protection from a casual attacker sniffing general traffic, but for any man-in-the-middle targeting the site specifically it is trivial to make the measure ineffective.

It's up to the provider whether they think this barely-more-than-plain-HTTP assurance is suitable for the kind of information that will be entered into the frame - except if that information contains credit card data, in which case they have an obligation to abide by the PCI-DSS rules requiring HTTPS. (Assessors are expected to verify that HTTPS indicators are visible in the browser chrome.)

seeing the browser's address bar unable to provide identity/encryption information is disconcerting.

Yes - independently of the question of actual security, this is poor perceived-security and may put some users off.

Without viewing the source of the page, how do I know where the iframe content is from?

Quite. Viewing source/DOM isn't something you can expect an average user to do.

Additionally, even if you verify the iframe is being served using HTTPS, there is nothing stopping the unsecured parent page from interfering with it with 'clickjacking' attacks, for example a keylogging overlay form.

Is relying on the godaddy seal sufficient?

Seals offer no security, as they are trivially spoof-able. They are nothing but a marketing exercise; CAs should be ashamed of this deliberately misleading behaviour.

unknownprotocol
  • 347
  • 1
  • 3
  • 11
bobince
  • 12,494
  • 1
  • 26
  • 42
  • All great points, especially the one about seals ;-) Since this was migrated, see also yesterdays's similar question: http://security.stackexchange.com/questions/31748/credit-card-forms-on-http-pages-a-mitm-risk – mr.spuratic Mar 02 '13 at 15:05
  • To me the most important point being that even if the "source" of the iframe looks correct, that is insufficient. In other words there is nothing the end user (even a savvy one) could look at to ensure the site is secure. (My interpretation of the answer) – Dave L. Mar 03 '13 at 02:31
  • @david: Yes, the user would have to check not only the current source of the iframe, but also that every element of the parent page was kosher before continuing - beyond impractical. – bobince Mar 03 '13 at 12:19
  • I'd agree with this, except that it seems to be relatively common practice to do this sort of thing even with credit card data, and there's a wide variety of sites that say this is OK. From a security standpoint it's clearly not OK, but is there something authoritative as to whether this meets the PCI standard (the wording seems pretty vague unless there's supporting interpretation somewhere) – mc0e Nov 18 '13 at 08:14
  • @mc0e: want to name and shame some sites saying this is OK? It's really, really not, and perhaps some attention needs to be brought to them (for example imagine releasing a FireSheep-like MitM that could do automated attacks on the page containing the iframe). The interpretation is in the PCI standard itself, in the instructions to assessors for 4.1.g: “For browser-based implementations ... Cardholder data is only requested if ‘HTTPS’ appears as part of the URL.” – bobince Nov 18 '13 at 10:02
  • Just google "https iframe pci" (without the quotes). At second place I see version 2 of the PCI standard, which says "Merchants may use a variety of technologies to implement e-commerce functionality, including payment-processing applications, application-programming interfaces (APIs), inline frames (iFrames), or hosted payment pages." It's less than clear though on any requirement for the page the iframe is on to use https, which is the relevant bit. In fact there's a lot of examples that go one step worse and just use https for the target url of the POST from the form. – mc0e Nov 19 '13 at 13:55
  • @bobince If you want a really big name to shame, we could go for VISA. http://en.wikipedia.org/wiki/3-D_Secure#Criticism – mc0e Nov 19 '13 at 13:55
  • Old, but worth a read: http://ha.ckers.org/blog/20090205/pci-question-of-the-day/ – mc0e Nov 19 '13 at 14:31
  • @mc0e: for all 3-D Secure's woes, when it's served in an iframe, the parent page is HTTPS. The problem is only that the party who owns the parent page's cert is less trustworthy than the party who owns the iframe's cert—consequently the user is forced to trust the merchant on each (non-passive) 3DS authentication, when it would have been much stronger had they been able to verify their bank. But it's still much better than the scenario of this question, which is no visible HTTPS at all. – bobince Nov 19 '13 at 14:43
1

Mixing HTTP and HTTPs pretty much destroys most advantages of HTTPS. For one, an attacker could present you with a malicious parent HTTP frame, with the iframe linking to his own site. The browser wouldn't find it suspicious. Neither would the user. The iframe URL is hidden, and the iframe isn't claiming to be HTTP. Nobody would know the difference, unless they checked.

The "seal" is just an HTML element, easily forged. I don't know how it works, but it probably is just a link to a GoDaddy page with SSL certificate information. The malicious iframe can just use the same HTML and link to the same GoDaddy page. Or, they can display the security information in a different manner (within the iframe itself, etc), and those who don't know what the original authenticator looks like will never know the difference.

Manishearth
  • 8,237
  • 5
  • 34
  • 56