Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

migrated from Mar 2 '13 at 11:46

This question came from our site for power users of web applications.

up vote 5 down vote accepted

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 a civilian to do.

Additionally, even if you verify the iframe is coming from 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 spoofable. They are nothing but a marketing exercise; CAs should be ashamed of this deliberately misleading behaviour.

share|improve this answer
All great points, especially the one about seals ;-) Since this was migrated, see also yesterdays's similar question:… – mr.spuratic Mar 2 '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) – david Mar 3 '13 at 2: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 3 '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 8: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

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.

share|improve this answer

Your Answer


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.