Confirmed users
2,615
edits
User:Dmose:Protocol Handler Security Review: Difference between revisions
User:Dmose:Protocol Handler Security Review (view source)
Revision as of 00:10, 7 November 2007
, 7 November 2007→Security and Privacy
| (6 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 = | ||
| Line 58: | Line 60: | ||
**** should avoid breaking future identity/auth mitigations, but not knowing what those are likely to be makes this hard | **** 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 | ||
**** Leaking credentials bug | **** 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. | **** 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}}) | *** register{Content,Protocol}Handler should be restricted to http and https handlers ({{bug|401343}}) | ||
| Line 66: | Line 71: | ||
***** 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 sites to determine | **** 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 == | ||