Security/Reviews/Firefox10/CodeEditor/FullScreenAPI

From MozillaWiki
Jump to: navigation, search

Introduce Feature

Full-screen API Security Review

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

What solutions/approaches were considered other than the proposed solution?

Why was this solution chosen?

  • Rather than only allowing full-screen on explicit user action (F11 or full-screen toolbar button)?
    • Having users hit F11 doesn't make the security hole go away. It's actually worse in some ways, because when the user does hit F11, there's no warning popup and no key restrictions.
  • Rather than requiring sites to be whitelisted?
  • Wanted to full-screen games and videos (with video controls), without making spoofing (especially phishing) too easy

Any security threats already considered in the design and why?

What we already do or plan to do before enabling full-screen API: We only grant requests for full-screen when: 

 1. Running in a user-generated event handler (same code path as pop-up blocking).
 2. Within the first second of running in a user-generated event handler.
 3. When all ancestor iframes have the mozallowfullscreen attribute.
 4. When there are no windowed plugins present (on non-MacOSX platforms).

When we enter full-screen: 

 1. We dim the <browser> element for the first 2s.
 2. We show a warning message for the first 4s after entering full-screen.

We exit full-screen mode when: 

 1. Keys not listed in https://wiki.mozilla.org/Gecko:FullScreenAPI#Proposed_Specification (e.g. alpha-numeric keys) are pressed (simulated events don't break us out of full-screen). 
 2. A windowed plugin is added to the(??) document.
 3. Navigation occurs.
 4. Focus changes to another tab. (e.g. Ctrl+Tab / command+tab)
 5. User hits Esc
 6. User hits F11

Planning on dispatching a "mozfullscreendenied" event when full-screen requests are not granted. Bug for warning UI: https://bugzilla.mozilla.org/show_bug.cgi?id=684625 Screenshot showing current warning: https://bug684625.bugzilla.mozilla.org/attachment.cgi?id=563296 Screenshot without warning: https://bug684625.bugzilla.mozilla.org/attachment.cgi?id=563272

  • Content can tell when it's in full screen mode and also exit full screen mode

Key brainstorming

  • Flash 10 exits full screen when users press escape, Control+w/command+w, and Alt+F4 (Windows).
  • This might change to making the "Press Esc" message appear again, instead of exiting full screen mode when a disallowed key is pressed. (+1 Tantek)
    • Note: Flash just drops the key events and does not put up a "Press Esc" message.
  • Which keys to allow:
    • Flash 10 allows Tab, Space, and arrow keys per http://kb2.adobe.com/cps/405/kb405548.html (+1 Tantek)
    • Jesse wants to allow meta keys (Shift, Ctrl, Alt, Cmd), which are common for games. This might mean we want to disallow Tab.
    • We want to allow a set of keys that will work well for video controls as well as games. (Opt+arrow, Home, End)
      • In Apple DVD Player, command-arrow(lef/right) does rewind/ff (+1 Tantek)
  • RoC: Avoid keys that could potentially produce text. Whitelist the rest, if we're not sure, don't put it on the whitelist.

Threat Brainstorming

  • site by site specific controls
    • not implemented, but we could
  • abuse by advertisers
  • web content taking exit key/Esc and not allowing exit of full screen mode - the code doesn't allow this
  • should switching apps (e.g. Alt+Tab on Windows) leave full-screen? spoof desktop
  • should the popup blocker heuristics be tightened for full screen activation? (specifically which event handlers are allowed to initiate)
    • e.g. only allow key-initiated popups for Space and Enter, or expect keyboard users to hit F11
  • triggering DOM full screen mode when already full screened with F11
  • convince user to triple-click somewhere. suddenly exit full screen. now you've launched a file from your desktop that the web page just put there! (UI race condition attack, like bug 162020)
    • maybe there should be an input-dead transition
    • but this attack works with popups too.

Conclusions / Action Items

  • [roc] List allowed keys for keyboard input in full screen mode (put them into the wiki please)
    • Do function keys make sense for web content? What about other keys (especially specialty keys commonly found on laptops like the thinkpad next page / previous page keys)?
  • Prevent web sites from using preventDefault to cancel exiting fullscreen (Esc is already covered) (F11, Cmd+Shift+F)
  • Non-visual warning for blind users (accessibility)
    • Low threat, this is usability and not security
  • [secteam] Check out feature in Nightly, need to enable a pref. Warning message patch (https://bugzilla.mozilla.org/show_bug.cgi?id=684625) hasn't landed yet.
  • Full-screen mode must be disabled when the browser/tab is not actively focused (https://bugzilla.mozilla.org/show_bug.cgi?id=685402)
  • [curtisk] F11 seperate discussion
  • [secteam] Review what user-initiated events are appropriate for activating full-screen mode
  • [cpearce] Change key handling so disallowed keys show same warning as when we first enter full-scren mode ("push escape to exit full screen mode") (https://bugzilla.mozilla.org/show_bug.cgi?id=691583)
  • [cpearce] Add domain name or page URL to "push escape to exit full screen mode" message
Retrieved from "https://wiki.mozilla.org/index.php?title=Security/Reviews/Firefox10/CodeEditor/FullScreenAPI&oldid=383682"