Security/Reviews/Firefox6/ReviewNotes/WebSockets

From MozillaWiki
Jump to: navigation, search

Tracking bugs

Webkit WebSockets bugs

Preliminary threat model

  • Authors - bsmith, dchan, imelven
    • reviewed, accepted and modified on 2011.06.14

Dataflow diagram

WebSockets DFD.png
Omnigraffle file File:WebSockets DFD src.tar.gz

Components

Component Description
Client browser The browser being used to load the webpage contents and participating in the websockets communication
WebSockets server The endpoint for the websocket communication. This server may be different from the server the webpage contents are retrieved from
Web server The server hosting the webpage responsible for initiating the websockets communication

Threat Categories

Threat category Description
Input validation Websockets adds another data consumer for potentially malicious data. Improper parsing/handling of this data may result in client compromise or data theft.
Denial of service Client - Websockets connections may receive an arbitrary amount of data. This can be used for memory exhaustion.
Server - Clients may be tricked into initiating requests to websockets servers and consuming server resources.
Cryptography Websockets uses cryptography primitives for random number generation and secure communication. These constructs are important in guaranteeing certain features in the websockets specification, e.g. authentication of servers, request authorizations
Browser feature consistency Websockets security policies should be consistent with existing browser features, e.g. XHR, private browsing
Privacy Websockets may perform cross-origin communications. This may result in data leakage.

Threats

Threat Description Component affected Category Notes / Mitigation
URI scheme attacks ws and wss are registered as protocols by the browser. Care should be taken to ensure that ws and wss are only used in the websockets context. A ws:// href should not have any effect in an anchor tag or the url bar. There may be more areas where a URI is expected in which ws/wss should do nothing. Client browser Browser feature consistency Patrick confirmed that the context should hold
Mixed content bug 662692 Browsers currently may warn when HTTP content is fetched over a HTTPS connection. The browser should warn when a ws connection is initiated from a secure page to maintain consistency. Failure to do so leads to a false sense of security. Client browser Browser feature consistency Bug filed, should not delay shipping in FX6, team is aware and dealing with the issue
CSP support Websocket compliance with CSP should be tested due to websockets enabling another transport medium for data. Client browser Browser feature consistency
  1. bsterne looking into proposal to extend CSP to support websockets src/origin along with other features
  2. if only default policy this is nonideal as other browsers may ignore this (Chrome would let this through in its current incarnation)
  3. [bsmith] bug: to not use default policy
HSTS support bug 664284 HSTS currently allows websites to opt-in to secure only communications. Websockets should follow this directive as well. Client browser Browser feature consistency
  1. Tests should be written for this
  2. Fix what tests show does not work
IFrame origin handling bug 664301 A parent page and child iframe may opt-in to cross-domain communication by setting their document.domain . In this event, what should the value of "Sec-WebSocket-Origin:" be? Should the page/frame be able to share the same websocket connection? Client browser Browser feature consistency
  1. Bug filed, however this may not be an issue discussion to continue via the bug
Private browsing mode / session restore Browser sessions and other data restored after exiting private browsing or a crash. Failure to handle current/pending websockets frames may result in data leakage. Client browser Browser feature consistency / Privacy
  1. The connections are torn down and not reused
CSRF / cookies A websocket connection is a normal HTTP request with specific headers. Connection / host specific data such as basic-auth and cookies may be sent in this request. Client browser Browser feature consistency
  1. Same base issue as bug 664031 ?
  2. Possible privacy issues as this is like CORS
    1. Cookies in websockets are treated as 3rd party cookies all the time? -> Yes; bug 574897 may be related and should be retested
  3. Investigate both bugs and address
Fragmented frames bug 664344 Fragmented data frames are denoted by a start/end frame with specific opcode/bits set. A server may use this feature to send data larger than the client's receive buffer size. Special care should be taken when reassembling and parsing the complete data to prevent unexpected workflows, e.g. overflow due to not allocating enough space. Client browser Input validation
  1. Need to decide how frames will be parsed
  2. Test needed for this behavior
  3. [christoph] fuzzing server?
    • Emailed Christoph
Frame handling bug 664344 The specification details the state-machine used for parsing websockets frames. The implementation code should be robust enough to handle situations such as incomplete fragmented frames, unfragmented frame during a fragmented frame, control frames after connection closed, etc. Client browser Input validation
  1. See above ^^ bug 665518
SSL/TLS Websockets may negotiate a secure connection over SSL/TLS . Browsers allow the user to specify which version of SSL/TLS to support. An error should occur if a noncompliant version of SSL/TLS is used. Client browser Cryptography
  1. [bsmith] bug: that will block un-prefixing, this is OK to go for now
Connection redirects A webserver may issue a 30x redirect as a response. Should websockets follow these responses? If so, what is the appropriate origin for the websocket Client browser Browser feature consistency
  1. Currently redirects are not done, the user can turn this on
  2. This may need re-evaluation this at the next version
  3. API to explicitly allow
  4. [dchan] bug: to track and work this
  5. the latest editor's draft of the websocket API (http://dev.w3.org/html5/websockets/) specifically says "When the user agent validates the server's response during the "establish a WebSocket connection" algorithm, if the status code received from the server is not 101 (e.g. it is a redirect), the user agent must fail the websocket connection." - this is only an editor's draft at this point but shows us which way the API seems to be leaning
Proxies Websockets are designed to function on top of a normal HTTP connection. A proxy in between the client and websockets server may potentially modify the data stream. Should separate proxy settings be exposed for websockets? Client browser / WebSockets server Input validation / Cryptography / Browser feature consistency
  1. This is already fixed and not an issue
  2. Should there be a specific webproxy proxy? --> the spec does mandate some proxy behavior, but the spec is silent currently on a specific proxy, we could pursue one if we find a reason to later
Cross-origin requests Websockets may be cross-origin. A malicious site could initiate a websockets connection with another server and cause the client to attack it. Cross-origin requests should behave in a way similar to XHR and CORS. Client browser / WebSockets server / Web server / Privacy Denial of service / Browser feature consistency
  1. issue is moot given other items
Callback manipulation Event listeners are attached to the websockets object. Websockets allow fragmented frames, during which time the listeners may change. Is data fully buffered before dispatch or can a listener receive partial messages? Client browser Input validation
  1. DOM handling of websockets
  2. JS does not do partial messages, so its not an issue
  3. message instead of stream API
Datatype manipulation Websockets support UTF-8 / binary datatype. The datatype can be modify during the connection. It may be possible to cause an inconsistent state by sending data then changing the datatype Client browser Input validation
  1. see above ^^
Default settings The browser should ship with a sane set of default preferences for websockets. Potential questions to ask are: Should websockets be enabled by default? Should the user be warned when a websocket connection is initiated? Should there be a mixed content dialog? Client browser Browser feature consistency / Privacy
  1. List of prefs set by websockets --> about:config websockets
  2. [dchan] bug: for MDN article assign to sherry keyword:devdocneeded
  3. [dchan] bug: add-on prefs to verifier for dangerous prefs
Chrome privileges Firefox chrome operates with less restrictions than content. Will there be additional functionality exposed to the chrome that isn't exposed to content? Client browser Browser feature consistency
  1. non-issue
Resource starvation bug 664305 A malicious client/server may send control frames and no data frames to keep a connection alive. This may be used to consume connections/ports on a target machine. Client browser / WebSockets server Denial of service
  1. bug already filed for this, likely not an issue

Preliminary look at Protocol and DOM specs - 2011.06.01

  • Attendance: bsmith, dchan, dveditz, bsterne, imelven

Files:

  • netwerk/protocol/websocket/nsIWebSocketProtocol.idl
  • netwerk/protocol/websocket/nsWebSocketHandler.cpp
  • content/base/nsIWebSocket.idl

non-protocol uses of ws:// wss:// URLs (addressbar, <img> etc)

Mixed Content:

  • Must change code so that https:// web page disallows ws:// sockets (wss:// only) or trigger mixed modes

Redirects:

  • Redirects are currently pref'd off, may be allowed in future; this pref'd off code was identified as problematic. Change code to ignore pref and never redirect?
  • If redirects are allowed then an originally secure socket can redirect to an insecure site
  • http://dev.w3.org/html5/websockets/#dom-websocket says redirects are NOT allowed, anything other than an initial 101 response is a fatal error
  • The IETF protocol says non-101 responses should be handled as a normal http response

Do sockets check with nsIContentPolicy listeners?

  • they should!
  • Patrick probably needs help writing the tests for this.
  • nsIContentPolicy is used for CSP *and* other content restriction mechanisms

Is HSTS implemented correctly? Does HSTS apply to the whole server or to a specific port? Look at the spec? We do agree that HSTS applies to WebSockets.

Need to audit the code for protocol-specific checks (especially for HTTP(S)) to make sure they were updated for WebSockets. (browser.js for address bar.)

What URI flags are used for WS:// and WSS://? checkLoadURI?

Should we attempt to load an external handler for ws:// or wss:// handler?

Load an iframe that has a websocket connection in it. Does this allow any attacks? Frames. What if the framed document has document.domain set?

evil.mit.edu 

   document.domain = mit.edu

cs.mit.edu 

   document.domain = mit.edu

Is this case, can the documents share a websocket? What is the Sec-WebSocket-Origin the original document, or the document.domain? What happens if you change document.domain when a WebSocket is active, does the WebSocket remain valid? (Blake, Jonas, JST.) Should it be similar to XSXHR? Is XSXHR implementation even right? Browser makers are trying to avoid adding document.domain handling to new specs, according to dveditz. (LocalStorage might not work, for example, according to dveditz.)

Compression mechanism - disabled by pref

Servers might not expect us to reuse a web connection as a websocket connection. Need to investigate whether we need to change our connection handling. W3C specification is unclear; IETF specification is unclear; specs do not match in specified behavior.

Cookies, HTTP authentication, Client certs, need cross-site cookie protection, HTTP-only cookies need to be properly handled. Compare to XHR with CORS. Need to write spec for how cookies are supposed to be handled and then check implementation against that spec. What happens when a 401 response is returned? How does HTTP auth work with websockets? How do client certs work in WebSockets (and XHR)?

W3C spec has specific requirements regarding cookies.

HTTP-only cookies, Secure Cookies

CORS-light - need to better understand differences between CORS and WebSockets CORS lite

WebSockets in workers - different principle

Malicious Servers: 

* Bad framing for buffer overflows and parsing errors
* Control frames mixed in with data frames, potential confusion regarding mixing data from frames
* Code audit + fuzzing server

Client attacking servers (e.g. server not expecting websockets at all).

Only one connecting connection to a particular host/port pair to prevent DoS according to the TLS spec (in security considerations). Do we implement this? Are there security problems with implementing this restriction? (See also proxy considerations.)

Should websockets be limited by the global limit of the number of connections per host?

Spec requires TLS Server Name Inidication for WSS. Implementation doesn't require this; PSM implements fallback to non-TLS SSL2.0/3.0 handshake without SNI. How does this work with TLS proxy to non-TLS websocket?

What happens on private browsing transitions? Do we send a close frame? Do we wait for a close? Do we clean up correctly/properly?

Are WebSockets responses cached?

  • It shouldn't be.

Chrome consideratoins: 

* HTTP auth spoofing
* Client certificate spoofing
* Mixed content indicators
* WS:// WSS:// in the address bar
* Are we registering a handler for it?
* On the command line

Can Chrome use websockets? If so, what principle gets sent? What happens when add-ons use it? What cookies/HTTP auth/etc.? Can JetPack get WebSockets access? Do we need to enable JetPack access?

Can Workers use websockets? If so, what principle gets sent?

URI parsing needs to be checked to make sure we are parsing WS:// and WSS:// URIs correctly, and not mis-interpreting HTTP URI constructions. Should be be silently stripping fragments? Are we?

What happens when we unregister callbacks? Need to make sure we don't crash on receiving data or any other notification that would cause a callback to be called.

Reusing connectoins deemed problematic. Need to understand how we would handle data after client closed connection and/or server indicated that it closed the connection and isn't intending to send more data, so that we don't interpret any following data as a response to a future request.

Need to handle server flooding us with data. Need to implement a maximum receive buffer size. Also, buffer size is increased linearly, instead of geometrically.

Is allocation used fallable?

Similarly, clients trying to send too much data that isn't being recv'd by the server, we don't want to DoS ourselves. Does the W3C spec have a way of saying "you are sending too much data; back off?" Is this implemented? Can this lead to OOM unnecessarily? It seems the spec is bad, because it doesn't expose the max buffered amount.

http://dev.w3.org/html5/websockets/#dom-websocket-send http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07#section-5

Spec wierdness: "If the connection is closed, this attribute's [bufferedAmount] value will only increase with each call to the send() method (the number does not reset to zero once the connection closes)." What happens when you send data in closed state?

Example from test-bug-603750-websocket.js: window.addEventListener("load", function () { 

 var ws1 = new WebSocket("ws://0.0.0.0:81");
 ws1.onopen = function() {
   ws1.send("test 1");
   ws1.close();
 };

 var ws2 = new window.frames[0].WebSocket("ws://0.0.0.0:82");
 ws2.onopen = function() {
   ws2.send("test 2");
   ws2.close();
 };

}, false);

Preliminary Security Discussion - 2011.05.27

  • Current implementation is expected to be safe enough to ship

Questions:

  • How stable is the API? Prefixing?
    • unsure
    • yes this will be prefixed
  • How stable is the protocol? Possibility of changes in the spec that could invalidate security assurances?
    • V.7 is in last call for the working group, no issues at this time. Changes to wire protocol unlikely.
    • if protocol changes we can detect incompatability if the version has a revision?�
  • Do we have a test for this?
    • Unknown, probably not -> will need to be checked between threat model and current test cases

How are we going to create a comprehensive threat model for this? How are we going to ensure that the threats identified in the threat model are addressed? Mapping threat model to tests?

    • Actions logged below
  • Current implementation allows a connection to issue HTTP connections and then switch to websockets.
    • Need to ensure that this is being done by other implementations (other clients and servers).
  • disagree that other implementations need to do this for us to lead on latency.
    • combination of threat model and test coverage

Can XHR now add WebSockets headers (for redirects) now that it couldn't add before we implemented WebSockets?

Do we support wss://? Do we allow mixed-content https:// + ws://? Should we? We don't need it for any backward compatibility, would be good to prevent mixed content from the start (i.e. only allow wss:// when the document is https://)

Does CSP apply to websockets?

Redirects? Cookies? Referer? Spec needs to be more expected.

Same-origin policy? CORS. Concatenating sec-origin headers on redirects.

Cross-protocol attacks.

  • Do we have tests that the cross-protocol attack prevention features actually prevent attacks?�What is the current thinking in the security research community regarding the cross-protocol attacks? Have we asked Barth and others?

What is the current thinking about WS security in general, in the security research community?

What happens when we get an HTTP response to a ws:// request? You always get an HTTP response to a ws:// request - ws is bootstrapped with http. Further detail depends on the specific context of the question.

Proxies: Do we correctly detect proxies (and LSPs) trashing the websockets connection? What happens when a regular HTTP response is returned for ws://? Response smuggling? - ^^ all handled by threat modeling and test coverage reivew no websockets data flows until the HTTP boostrapped handshake is complete.

Fuzz testing?

Cryptographic requirements of keys.

Concatenate origins in headers on redirect.

Possible that connection will fall back to SSL 3.0 without SNI extension.

Key used to protect against cross-protocol attacks is not random (patch pending review).

"Act as if the user agent had received a set-cookie-string for the document's address, consisting of the cookies set during the server's opening handshake. [COOKIES] [RFC3629] [WSP]" - This part of the spec is wrong, need to make sure implementation doesn't implement wrongly spec'd semantics.

Issues:

  • TBD

Actions:

  1. Threat model
    1. bsmith/dchan are accountable for the threat model working with mcmanus and team Target: 2011.06.10
    2. meeting to review threat model TBD [week of 06.13 match up with testing]
  2. Pen testing [dependant on TM] [meet week of 06.13 to flesh out testing]
    1. dchan
  3. Fuzz Testing
    1. christoph?
  4. Implementation review [target 06.10]
    1. API: Jonas
    2. Protocol: imelven resources:bsmith,honza
Retrieved from "https://wiki.mozilla.org/index.php?title=Security/Reviews/Firefox6/ReviewNotes/WebSockets&oldid=383663"