[websec] Frame-Options header and intermediate frames

[David Ross <[e-mail]>]

Michal Zalewski and Eduardo Vela brought up an interesting scenario pertaining to the Frame-Options header.  Specifically, if only the top level page URL is validated w.r.t. SAMEORIGIN or ALLOW-FROM, malicious ads or other unsafe content in an intermediate frame could re-frame content from the top level site for the purposes of clickjacking.

In the RFC draft currently there is the following:

---
SAMEORIGIN
...
	[TBD]current implementations do not display if the origin of
        the top-level-browsing-context is different than the origin of
        the page containing the FRAME-OPTIONS header.
---

There's a good argument that sites attempting to avoid attacks such as phishing and clickjacking would not want to frame arbitrary content.  Users really only have an easy way to make immediate and valid trust decisions about the origin of the top level page, not frames contained within those pages.  But sites that frame arbitrary content do exist in the real world, for better or worse.  While there are different philosophical viewpoints on cross-domain framing, there doesn't seem to be any reason to avoid creating a ValidateAllAncestors flag on Frame-Options which would instruct the browser to validate the URL of each hosting frame up to the top level.  Given this, sites that frame arbitrary content could at least make use of SAMEORIGIN and ALLOW-FROM for their intended purpose.

We'd like to get the intermediate frame issue documented and describe the optional ValidateAllAncestors flag in the RFC draft.

David Ross
[e-mail]