CODEWITHSUNDEEP
firefoxcookieswebsocket
Stevko
Stevko

Reputation: 4505

Firefox leaking cookies across Websocket hostdomains

Within Firefox 9 & 10 using Firebug and Live Headers, I am seeing the websocket request/response pairs being sent across domains but with the wrong Cookie: contents.

Give two urls -

Base web page - http://www.mysite.test/mywebapp

Websocket url - http://stompeserver.mysite.test/stomp

The browser seems to be sending the cookies for the base page hostname rather any cookies associated with the secondary hostname. i.e. the JSESSIONID cookie loaded with the base web page is being echoed to the external connection.

Is this a bug or expected behavior? Nowhere have I seen how to websockets are suppose react to cookies.

IMO, this can be a really serious security violation by exposing a site's cookies to an external websocket service.

Updated to firefox 10 and still see an issue.

Below is a slightly clarified Live Headers trace of two back to back connections

The JSESSIONID and CLIENT_LOCALE cookies are copied to from 9443 the app server to 61623 the mq server.

----------------------------------------------------------
https://myapp.com:9443/server/themes/standard/public/gwt/xxstandard/images/logout-icon.png

GET https://myapp.com:9443/server/themes/standard/public/gwt/xxstandard/images/logout-icon.png HTTP/1.1
Host: myapp.com:9443
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: https://myapp.com:9443/server/example.htm?gwt.codesvr=127.0.0.1:9997&log_level=INFO
Cookie: JSESSIONID=0000wCOpgfIsSNOz2lL22O5LOiI:-1; CLIENT_LOCALE=en_US; 
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.1 200 OK
Date: Thu, 16 Feb 2012 19:02:55 GMT
Content-Type: text/plain
Last-Modified: Wed, 29 Jun 2011 20:44:11 GMT
Content-Length: 669
Content-Language: en-US
Server: WebSphere Application Server/7.0
----------------------------------------------------------
http://myapp.com:61623/stomp

GET http://myapp.com:61623/stomp HTTP/1.1
Host: myapp.com:61623
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Proxy-Connection: keep-alive
Sec-WebSocket-Version: 8
Sec-WebSocket-Origin: https://myapp.com:9443
Sec-WebSocket-Key: FToA/HGiVQN3CbGOgNffMA==
Cookie: JSESSIONID=0000wCOpgfIsSNOz2lL22O5LOiI:-1; CLIENT_LOCALE=en_US; 
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Connection: Upgrade

HTTP/1.1 101 Switching Protocols
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Accept: 5lqrLU4mbPiEasSn4gqOlqWvGgw=
----------------------------------------------------------

Upvotes: 3

Views: 1128

Answers (1)

oberstet
oberstet

Reputation: 22051

Same-origin policy and CORS doesn't apply to WebSockets.

With WS, a "origin" HTTP header is sent in the initial WS opening handshake, and for browsers, this origin header MUST contain hostname of the server that originally served the HTML/JS that opens the WS.

The WS server is then free to accept/deny.

With non-browser WS clients, the origin header may or may not be present, and may contain anything.

Cookies: it's not specified by the WS spec. See Patrick's response (Firefox WS developer) here

http://www.ietf.org/mail-archive/web/hybi/current/msg08017.html

Upvotes: 3

Related Questions