Security/Reviews/Firefox6/ReviewNotes/ServerDomEvents: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with "2011.06.27 https://bugzilla.mozilla.org/show_bug.cgi?id=338583 Add support for Server-Sent DOM Events (Remote Events) http://dev.w3.org/html5/eventsource/ https://bugzilla.mozill...")
 
No edit summary
Line 1: Line 1:
2011.06.27
== Server Sent DOM Events 2011.06.27 ==
https://bugzilla.mozilla.org/show_bug.cgi?id=338583
*Add support for Server-Sent DOM Events (Remote Events) {{bug|338583}}
Add support for Server-Sent DOM Events (Remote Events)
* Spec  http://dev.w3.org/html5/eventsource/
http://dev.w3.org/html5/eventsource/
* Related Bugs
https://bugzilla.mozilla.org/show_bug.cgi?id=664179
** {{bug|664179}}
In aurora for 6 (without CORS)
* Current Status: In aurora for 6 (without CORS)
Agenda:
 
== Introduce Feature (5-10 minutes) ==
== Introduce Feature ==
- Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)  
* Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)  
** support data that a server can push to a web page
** support data that a server can push to a web page
** only supports http[s] today but could support other protocols in the future
** only supports http[s] today but could support other protocols in the future
- What solutions/approaches were considered other than the proposed solution?  
* What solutions/approaches were considered other than the proposed solution?  
** multi-part xmlhttp is also being implemented as other browsers support this
** multi-part xmlhttp is also being implemented as other browsers support this
** websockets (which are two-way) requires big changes to servers
** websockets (which are two-way) requires big changes to servers
- Why was this solution chosen?  
* Why was this solution chosen?  
- Any security threats already considered in the design and why?  
* Any security threats already considered in the design and why?  
** same domain connections
** same domain connections
== Questions ==
== Questions ==
* does support for http mean we also support https?
* does support for http mean we also support https?
* content has to opt-in to recieve messages?
** yes but should be tested and confirmed as correct
** event source object recieves the messages
* content has to opt-in to receive messages?
** event source object receives the messages
*** it's not in the document tree, so there's no capture/bubbling phase
*** it's not in the document tree, so there's no capture/bubbling phase
* two parallel listeners... what happens?
* two parallel listeners... what happens?
** both get a reference to the same event (no race condition)
** both get a reference to the same event (no race condition)
** do they share a (network) connection, or are there multiple connections opened?
** do they share a (network) connection, or are there multiple connections opened?
*** Different connections? TODO: check to make sure they both see the same event object in the client.
*** Different connections? '''TODO:''' check to make sure they both see the same event object in the client.
*** even if they are in different pages??? <-- good question, maybe separate pages should not share connection, but same page should (spec says?)
*** even if they are in different pages??? <-- good question, maybe separate pages should not share connection, but same page should (spec says?)
* how is the URI in the constructor validated (ie check it's not a chrome URI or some other funky kind of URI) ?
* how is the URI in the constructor validated (ie check it's not a chrome URI or some other funky kind of URI) ?
* how does CSP factor into EventSource usage ?
* how does CSP factor into EventSource usage ?
** it's currently type script, but should probably be changed to type XHR (or its own type)
** it's currently type script, but should probably be changed to type XHR (or its own type)
* [dveditz] if you're on an HTTPS page and the event source references HTTP URL, does the mixed content UI get triggered (hide secure badging for the page)?
* If you're on an HTTPS page and the event source references HTTP URL, does the mixed content UI get triggered (hide secure badging for the page)?
** Not an issue for same-origin, but for CORS support needs to be considered.
** Not an issue for same-origin, but for CORS support needs to be considered.
** Do we want to consider https-using-http to be "mixed display" (allowed) or "mixed scripting" (blocked) when we adopt this distinction from chromium? (how about equivalent to XHR -- then we can deal with them together -- probably "mixed scripting")
** Do we want to consider https-using-http to be "mixed display" (allowed) or "mixed scripting" (blocked) when we adopt this distinction from chromium? (how about equivalent to XHR -- then we can deal with them together -- probably "mixed scripting")
Line 35: Line 37:
* interaction with bfcache?
* interaction with bfcache?
** frozen document gets its connections closed. thawed document gets reconnected.
** frozen document gets its connections closed. thawed document gets reconnected.
== Threat Brainstorming (30-40 minutes) ==
 
== Threat Brainstorming ==
=== Server attacking client ===
=== Server attacking client ===
* [dveditz] DoS by opening a bunch of connections, maxing out our limits
* DoS by opening a bunch of connections, maxing out our limits
** differs from XMLHttpRequest because it is expected to be long-lived (but same risk as multiple long-lived XHRs)
** differs from XMLHttpRequest because it is expected to be long-lived (but same risk as multiple long-lived XHRs)
** maybe we should have a per-tab limit so a single tab can't eat your networking limits
** maybe we should have a per-tab limit so a single tab can't eat your networking limits

Revision as of 19:00, 27 June 2011

Server Sent DOM Events 2011.06.27

Introduce Feature

  • Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
    • support data that a server can push to a web page
    • only supports http[s] today but could support other protocols in the future
  • What solutions/approaches were considered other than the proposed solution?
    • multi-part xmlhttp is also being implemented as other browsers support this
    • websockets (which are two-way) requires big changes to servers
  • Why was this solution chosen?
  • Any security threats already considered in the design and why?
    • same domain connections

Questions

  • does support for http mean we also support https?
    • yes but should be tested and confirmed as correct
  • content has to opt-in to receive messages?
    • event source object receives the messages
      • it's not in the document tree, so there's no capture/bubbling phase
  • two parallel listeners... what happens?
    • both get a reference to the same event (no race condition)
    • do they share a (network) connection, or are there multiple connections opened?
      • Different connections? TODO: check to make sure they both see the same event object in the client.
      • even if they are in different pages??? <-- good question, maybe separate pages should not share connection, but same page should (spec says?)
  • how is the URI in the constructor validated (ie check it's not a chrome URI or some other funky kind of URI) ?
  • how does CSP factor into EventSource usage ?
    • it's currently type script, but should probably be changed to type XHR (or its own type)
  • If you're on an HTTPS page and the event source references HTTP URL, does the mixed content UI get triggered (hide secure badging for the page)?
    • Not an issue for same-origin, but for CORS support needs to be considered.
    • Do we want to consider https-using-http to be "mixed display" (allowed) or "mixed scripting" (blocked) when we adopt this distinction from chromium? (how about equivalent to XHR -- then we can deal with them together -- probably "mixed scripting")
  • can file:// urls construct an EventSource object ? (MIME type should stop this, since the local file won't have the magic text/eventsource MIME type)
  • interaction with bfcache?
    • frozen document gets its connections closed. thawed document gets reconnected.

Threat Brainstorming

Server attacking client

  • DoS by opening a bunch of connections, maxing out our limits
    • differs from XMLHttpRequest because it is expected to be long-lived (but same risk as multiple long-lived XHRs)
    • maybe we should have a per-tab limit so a single tab can't eat your networking limits
  • the spec specifies the event stream format and how to parse it - possible input validation threat here. how complex is the parser? should it get fuzzing and/or extra review?
  • Does this allow events to be fired (at web pages) at times when it would be unusual for events to fire?
  • Do we have tests to ensure we don't crash/deadlock/leak if a script responds to receiving an event by:
    • closing the tab
    • closing the window
    • closing the socket
  • Server could find out whether GC happened by seeing whether a thawed document has an EventSource reconnection

Server attacking other server

  • If you've already XSSed a site, could EventSource let you do things you weren't previously able to accomplish? (CORS doesn't help here.)
    • Site must opt in with MIME type and CORS

MITM attacks

  • At EOF, does that cause a partial message to be delivered to script? Spec issue!!!

Data attacking server & client

  • [dveditz] Data validation / sanitization of ID, which browser re-sends to server upon reconnection
  • What happens if there's a nul byte? (particularly when data is handled in C code)
  • Data contains line break, causing client to think there's a separate message
    • Does every participant agree on which characters constitute line breaks?
      • Spec is clear: \n \r or combinations thereof.

Conclusions / Action Items (10-20 minutes)