3

I'd like to protect against clickjacking using the X-Frame-Options header, but we occasionally frame secure content on the insecure version of our site1:

A transparent secure iframe for submitting payment info is loaded inside the insecure version of the site.

Since it looks like only Firefox currently supports the ALLOW-FROM form of the header, I'm considering conditionally serving the header:

  • By default, include X-Frame-Options.
  • If your referrer is ^(.*\.)?example.com$, leave the header out.

It seems like this would work, and it fails safe: if someone's browser doesn't send a referrer or a corporate firewall strips it out, they don't get to pay us (which is bad), but our content can never be framed on third-party sites (which would be worse).

How would this strategy work in the real world?

1 Some of our ad partners historically haven't supported serving ads over HTTPS. We're investigating whether this has changed.

EDIT: To clarify, we only nest a secure iframe in an insecure page in one case: an ad-supported user purchasing something for the first time inline. We can't currently serve the whole site over HTTPS for those users and we don't want to send them to a separate page or open a popup window.

Ad-free users get HTTPS all the time, and we're investigating the feasibility of serving ads over HTTPS too.

s4y
  • 131
  • 1
  • 5
  • Could you please clarify what the question is (e.g. what you are asking)? – Jonathan Dec 17 '14 at 23:25
  • @Jonathan Specifically, I'm wondering if a) enough users send no referrers for this to be a problem and, b) if there are any attacks against this solution. – s4y Dec 17 '14 at 23:34
  • Is your secure content supposed to be accessible from third party sites, or will your users always be in your domain when doing things like payment/etc? – Andrew Hoffman Dec 18 '14 at 14:45
  • Any reason why you wouldn't/can't just use the ALLOW-FROM option? From what I've read, current versions IE and Mozilla both support it. Chrome is unconfirmed at this point. – k1DBLITZ Dec 18 '14 at 15:06
  • @AndrewHoffman Our domain only. – s4y Dec 18 '14 at 18:39

1 Answers1

2

First I'd advise simplifying the problem by getting rid of the secure content being served over a frame.

enter image description here

Not a dig against you or your organization, but we're trying to train the world not to trust forms like the one you provided an image for. I know this isn't part of your question, but a Secure Transaction image is no substitute for that https cert.

If your 3rd party partners have no need to function as a portal for your secure content, then eliminating that possibility would simplify your problem. Implement no-exceptions anti-click-jacking for your secure content. Do the whole page as HTTPS, not just a form or a frame. If someone uses my free wifi hotspot at an airport, I can easily jack the whole form or frame and replace it with my own that looks identical, complete with Secure Transaction image.

Back on point, with the elimination of secure content simplifying the issue some, what remains is a browser compatibility problem with X-Frame-Options.

Theres a question over at stack overflow that discusses this, but it doesn't seem to truly solve the problem, but does answer the question: Browser compatibility continues to be a problem.

Another thing you might consider, I've done some work with porthole.js before for cross-frame communication and one of the things it made me think about is having the ability for a child frame to validate its parent, and for the parent to validate the child frame.

You can quickly check porthole's compatibility by visiting their demo site with the browsers that you care about supporting.

Additionally you could have your partners identify themselves with a querystring.

<iframe src="www.site.com/?partner=3tqdHB"></iframe>

Then when your click-jacking detection detects a parent window, check to see that the proper querystring parameter exists. If it does, challenge the parent frame to prove it's identity, sending a nonce.

The parent frame could then use the provided nonce with it's key to prove it's identity to you.

If everything works out, don't execute your kill script, otherwise, execute kill script.

Community
  • 1
Andrew Hoffman
  • 1,987
  • 14
  • 17
  • 1
    I totally agree with your first point and added some extra info to the question, check it out. Power users can verify the authenticity of the iframe like this: http://i.stack.imgur.com/C60CG.png – s4y Dec 18 '14 at 18:56
  • We've got a porthole-like solution up and running, and your idea of cryptographically verifying that the frame is embedded on our site is an cool idea. It seems complex though, and happens on the client side (i.e. we couldn't use `X-Frame-Options`) — I liked my solution because it was simple and could be implemented server side. I'll check out your idea more after the holidays. – s4y Dec 18 '14 at 19:02