Confirmed users
2,615
edits
User:Dmose:Protocol Handler Security Review: Difference between revisions
Jump to navigation
Jump to search
User:Dmose:Protocol Handler Security Review (view source)
Revision as of 00:10, 7 November 2007
, 7 November 2007→Security and Privacy
| (14 intermediate revisions by the same user not shown) | |||
| Line 38: | Line 38: | ||
To actually see the registration in action, go to [http://people.mozilla.com/~ctalbert/] and select one of the web mail handlers. After you've accepted the registration, click the test link. It should bring up the compose window for the webmail app, though the header fields will not (at the moment) be populated correctly. Another example is to click on a webcal: link in a nightly; this will take you to a test handler that we have set up. | To actually see the registration in action, go to [http://people.mozilla.com/~ctalbert/] and select one of the web mail handlers. After you've accepted the registration, click the test link. It should bring up the compose window for the webmail app, though the header fields will not (at the moment) be populated correctly. Another example is to click on a webcal: link in a nightly; this will take you to a test handler that we have set up. | ||
* Current dialog behavior is suboptimal; filed {{bug|402771}} to sort this out. | |||
= Design Impact = | = Design Impact = | ||
== Security and Privacy == | == Security and Privacy == | ||
* What security issues do you address in your project? | * What security issues do you address in your project? | ||
* Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing? | * Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing? | ||
** mime-types.rdf corruption / missing | ** mime-types.rdf corruption / missing | ||
*** will use reasonable defaults | |||
** application pref file (firefox.js or equivalent) missing | ** application pref file (firefox.js or equivalent) missing | ||
*** falls back to secure config (everything blacklisted) | |||
** user prefs.js missing | ** user prefs.js missing | ||
*** falls back to default config (believed secure) | |||
* Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project. | * Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project. | ||
** Assumptions | ** Assumptions | ||
| Line 55: | Line 57: | ||
** Potential Risks | ** Potential Risks | ||
*** Phishy? (Encourages in-browser auth?) | *** Phishy? (Encourages in-browser auth?) | ||
**** not notably worse than current situation | |||
**** should avoid breaking future identity/auth mitigations, but not knowing what those are likely to be makes this hard | |||
*** The HTML5 spec has a [http://www.whatwg.org/specs/web-apps/current-work/#security3 list of possible security issues] that should be gone through | *** The HTML5 spec has a [http://www.whatwg.org/specs/web-apps/current-work/#security3 list of possible security issues] that should be gone through | ||
*** register{Content,Protocol}Handler | **** spec: "should NEVER send https URIs to third-party sites"; filed {{bug|402144}} filed | ||
*** | **** need to handle Intranet URI leakage as per HTML5 4.10.2.1; filed {{bug|402138}} | ||
**** Leaking credentials; filed {{bug|402152}}. | |||
**** Need to be sure only appropriate handlers can be overridden; filed {{bug|402788}}. | |||
**** Done; things we need to address now accounted for in this document with bugs filed. | |||
*** register{Content,Protocol}Handler should be restricted to http and https handlers ({{bug|401343}}) | |||
*** Need to decide on uses of web-handled URIs in contexts other than in href attribute of A element ({{bug|400886}}) | |||
*** old warning dialog has been removed; filed {{bug|402151}} | |||
*** old warning dialog has been removed | |||
***** if it's unacceptably risky, we shouldn't be doing it at all | ***** if it's unacceptably risky, we shouldn't be doing it at all | ||
***** unclear how much a warning dialog helps anyway | ***** unclear how much a warning dialog helps anyway | ||
*** non-SSL handlers in combination with DNS MiTM attacks (eg bogus Wifi APs) | *** non-SSL handlers in combination with DNS MiTM attacks (eg bogus Wifi APs) | ||
**** a problem, but not of the magnitude of add-on downloads, because this code doesn't execute locally with privs. Decided to continue to allow handler sites to determine whether or not to require SSL. | |||
** Misc | ** Misc | ||
*** | *** notification bar for handler registration insufficiently clear; filed {{bug|402245}} | ||
*** | *** details and editing of handler info not available from prefs UI; filed {{bug|402252}} | ||
*** | *** web-based protocol handler "already been added" UI could use some tuning; filed {{bug|402258}} | ||
*** | *** a rogue site could trick a user into registering a handler that would go to a large mail site (e.g. Yahoo mail) but via a redirector that could then sniff all requests; filed {{bug|402287}} | ||
*** verify that we don't leak various information; filed {{bug|402641}} | |||
*** need to decide on best behavior re opening in new tab/window; filed {{bug|402736}} | |||
*** there are some more bugs that need to be filed; dmose is working on paring down this; these are unlikely to be blockers: | |||
**** allow user to say "no and never again" | |||
**** credential leakage; url -> handler (yes for fx3), web page -> handler (no for fx 3) verify | |||
**** filter URI specs based on spec-specific criteria: X- headers out of mailto | |||
**** enforce URI syntax restrictions | |||
**** test registration spamming | |||
**** RDF serializer should be audited for quoting | |||
== Exported APIs == | == Exported APIs == | ||
| Line 156: | Line 167: | ||
== Other == | == Other == | ||
Other issues to check: non-idempotent URI types | |||
= Discussion & Implications = | = Discussion & Implications = | ||