Anti-Clickjacking Requirements

From Web Security

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