Anti-Clickjacking Requirements
Requirements
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
Attack cases:
- 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.
Questions
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?
Ideas
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