Opt-In protection for each HTTP resource.
- Must identify both control and necessary context
- May need to identify timing
Address cases that attackers are motivated to use. Success to be determied by observed threat landscape, not theoretical perfection in closing UI Redressing side channel
- Transparent overlay of attack content
- Click-through overlay of genuine content
- Double-click, close window to pop-under of genuine content
- Rapid de-obscuring of genuine content
- Rapid movement of genuine content
- Phantom mouse cursor
- Misleading context (e.g. disguise payment amount or recipient)
More details on the attack cases can be found here: http://www.w3.org/Security/wiki/Clickjacking_Threats
Prefer to express requirements as policy language and intended semantics, rather than specific technical implementation. Suggested implementations may be described in a non-normative fashion, but different user-agents may have different needs and facilities. (e.g. mobile vs. desktop browser)
Non-Requirements for v1
Protecting existing content that does not opt-in to protection.
Addressing non-visual interface interference, such as simultaneous audio.
Do we attempt to protect against (with the same mechanism):
- Drag and drop attacks (perhaps better as Frame-Options tokens: no-drag, no-drop)
- Fake-captcha type info disclosure attacks
Re-use of Frame-Options policy channel?
Screen-shot compare: rendered at OS-level vs. rendered by layout engine
Protected UI element: interactive element (swipe, countdown) guaranteed to be visible + defined context during interaction