SecurityEngineering/Jan2013WorkWeek/02-CSP Planning

From MozillaWiki
Jump to: navigation, search

CSP 1.0 and beyond

3:00pm Monday 1/14

  • What do we do about reports? The spec doesn't say we need restrictions on where reports can go (report-uri valid targets).
    • We give more info then spec says to. (Line numbers, etc)
    • We restrict targets to same ETLD+1, but many others don't want restrictions -- people don't think ETLD+1 is a good idea
      • Example: lots of domains, want one report handler
      • Could we send "lite" reports to cross-domain targets? More robust reports go to same-domain or same ETLD+1.
      • Can we block report-uri in meta tags (just the HTTP header)? That would reduce the attack surface.
    • What to do with multiple policies intersected with multiple report uris?
  • 1.0 landing strategy:
    • When inline style blocking lands, then flip on the 1.0 parser (v21)
    • let the pref and csp1.0 ride through to release, then push a pref removal patch in nightly after it's shipped to all users. Can uplift if we wanna delete the pref sooner.
    • Must stop proliferation of security prefs! Too many. Aggressively remove unnecessary prefs.
  • What is left to do (1.0 follow-ups, must-fix, fixed by 1.0, triage open CSP bugs, etc)?
    • TODO: implement multiple policy support (not intersection)
    • Couple of CSP meta bugs (id=csp and id=csp-w3c)
    • Need to Triage and clean up open bugs (and fix them)
    • Need to run 1.0 parser against external CSP test suites (i.e., by Erlend Oftedal and W3C)
    • Need to move error messages over to web console
    • Figure out how to deal with add-ons that inject web content (argument for giving exceptions to add-on generated content from dveditz: W3C tends to favor user's operations over web site's operations, so maybe add-on content injection should work regardless of what the CSP says).
  • Make deprecation plan for X-CSP...
    • Ideas/input: Coordinate around ESR? Deploy telemetry to identify use of old header?
    • Get rid of the X- header by 22/23 so it doesn't hit the ESR. Aim for > one release before next ESR.
    • Direct outreach to top 10000 sites that are actually using CSP (need scanner to find out who's using these)
    • Bonus: we won't break sites by turning CSP off (we'll just make them less secure)
    • Add strong deprecation warnings to the code one release/6-weeks after 1.0 lands (so they show up in the web console when old X- header is used) (If this is in 22 deprecation should wait until 23)
  • What of 1.1 do we want to implement? https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#form-action--experimental
    • 0 - X-Frame-Options-like thing in CSP? Maybe support the frame-options stuff.
    • 4 - Meta tag support?
    • 6 - Path support in source expressions? (currently we ignore them)
    • 2 - Sandbox directive?
    • 5 - Find alternatives to the script and css nonce stuff?
      • Allow scoped inline CSS? Can create a style attribute that only applies to the element that is a sibling of the <style> element (but not parents of the node).
      • Allow CSS attributes? -- more granular blocking of dangerous CSS.
    • Have web console convert X-Content-Security-Policy -> Content-Security-Policy in warnings about the old header?
    • 6 - Plugin-types (type, not source for plugins)?
    • 0 - XSS reflection switch (XSS filter disabling)?
    • 0 - Form-action?
    • 6 - Script-nonce? For performance reasons, some inline scripts should be allowed. Use a token to identify them. Not to be confused with script-digest. Better than allowing inline scripts.
    • -3 - contentSecurityPolicy DOM object to inspect policies, get violation alerts, etc.
      • and possibly to allow adding policies, too.
    • 0 - Key pinning via CSP directive (for specific content)?

Moar things to extend CSP:

    • Take input from B2G app developers -- may have needs
    • Other developer tools? Should we work on/deploy a developer tool for writing sites with CSP?
    • Figure out how HSTS and CSP "don't" work together.
  • What kind of communication/evangelism should we do?
    • Animated video?
    • OWASP cheat sheet
    • blog post -> cross posted to security blog ?
      • one when CSP 1.0 lands in Nightly
      • another when CSP 1.0 makes it to release

Action Items:

  • [sid] csp bug triage (schedule meeting and DO IT) with ian, tanvi, dveditz
  • [sid] csp test suite checking -- check against external test suites to find bugs, make sure the tests are good ones to trust. (who will ask security qa and get ian suckered in to help)
  • [ian] file bug for implementing multiple policy support (not intersection) -- would obsolete bug 552523
  • [ian] identify top sites (of top 10000) that use CSP so we can contact them about deprecation (if they use the prefixed header) - see http://www.veracode.com/blog/2012/11/security-headers-report/
  • [ian] add deprecation warnings to web console when old X- policy is used - https://bugzilla.mozilla.org/show_bug.cgi?id=821877
  • [dveditz] figure out what to do about add-ons that inject content (it should be allowed) See bug 615708
  • [fbraun] talk to devtools about making something to help devs making CSPs.
  • [ian] will post to mailing list - is it possible to allow inline style attributes only since these don't have selectors and that's the threat we're concerned about
  • [ian] will post to mailing list about report-uri and restrictions - idea is to remove restricition but only send possibly sensitive data in the eTLD+1 case (this is along the lines of what adam suggested for line #'s - "to use the same mitigation use use for window.onerror: include this information for same-origin scripts and for scripts loaded with CORS."
Retrieved from "https://wiki.mozilla.org/index.php?title=SecurityEngineering/Jan2013WorkWeek/02-CSP_Planning&oldid=500164"