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

Jump to navigation Jump to search

Security/Reviews/Firefox6/ReviewNotes/WebSockets (view source)

Revision as of 20:55, 6 June 2011

3,388 bytes added ,  6 June 2011
no edit summary
No edit summary
Line 1: Line 1:
==Preliminary look at Protocol and DOM specs==
==Preliminary look at Protocol and DOM specs - 2011.06.01==
6/1/2011 - bsmith, dchan, dveditz, bsterne, imelven
* Attendance: bsmith, dchan, dveditz, bsterne, imelven


netwerk/protocol/websocket/nsIWebSocketProtocol.idl
Files:
netwerk/protocol/websocket/nsWebSocketHandler.cpp
* netwerk/protocol/websocket/nsIWebSocketProtocol.idl
content/base/nsIWebSocket.idl
* netwerk/protocol/websocket/nsWebSocketHandler.cpp
* content/base/nsIWebSocket.idl


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


Mixed Content:
===Mixed Content:===
* Must change code so that https:// web page disallows ws:// sockets (wss:// only) or trigger mixed modes
* Must change code so that https:// web page disallows ws:// sockets (wss:// only) or trigger mixed modes
Redirects:
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?
* 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?
Line 17: Line 17:
* The IETF protocol says non-101 responses should be handled as a normal http response
* The IETF protocol says non-101 responses should be handled as a normal http response


Do sockets check with nsIContentPolicy listeners? they should!
Do sockets check with nsIContentPolicy listeners?  
* they should!
* Patrick probably needs help writing the tests for this.  
* Patrick probably needs help writing the tests for this.  
* nsIContentPolicy is used for CSP *and* other content restriction mechanisms
* nsIContentPolicy is used for CSP *and* other content restriction mechanisms
Line 66: Line 67:
What happens on private browsing transitions? Do we send a close frame? Do we wait for a close? Do we clean up correctly/properly?
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.
Are WebSockets responses cached?  
* It shouldn't be.


Chrome consideratoins:
Chrome consideratoins:
Line 111: Line 113:
   };
   };
}, false);
}, false);
==Preliminary Security Discussion - 2011.05.27==
* [[/Platform/Features/Websockets|WebSockets]]
* {{bug|640003}}
*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.
===Issues:===
*TBD
===Actions:===
# Threat model
## bsmith/dchan are accountable for the threat model working with mcmanus and team Target: 2011.06.10
## meeting to review threat model TBD [week of 06.13 match up with testing]
# Pen testing [dependant on TM] [meet week of 06.13 to flesh out testing]
## dchan
# Fuzz Testing
## christoph?
# Implementation review [target 06.10]
## API: Jonas
## Protocol: imelven resources:bsmith,honza
* Test Suite (interoperability)
** greg wilkins of jetty has begun an effort on this http://www.ietf.org/staging/draft-wilkins-hybi-websocket-tests-00.txt
* Check Point meeting next week
Curtisk
canmove, Confirmed users, Bureaucrats and Sysops emeriti
2,776

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/315885"

Navigation menu