728375 - MozWebSocket exposing cookies across hostname/domains

Status: RESOLVED INVALID

(Core :: Networking: WebSockets, defect)

Description

[Andy Stevko]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1
Build ID: 20120208060813

Steps to reproduce:

Open a stomp/websocket from a WebSphere Applicatin Server hosted page to an Active MQ JMS server.



Actual results:

cross posted from http://stackoverflow.com/questions/9304283/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.

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 trimmed 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. I had clear all cache prior to loading this page and this is the first connection to the mq server. There is no chance that it had the same sessionid cookie.

----------------------------------------------------------
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=
----------------------------------------------------------




Expected results:

The cookies on the websocket connection should be empty in this scenario.
Other scenarios should build the cookies from the set-cookies set by the mq server.

Some of this behavior changed from FF9 to FF10 where it would confuse the page context and set the cookies from the MQ server into the web page context. This would manifest itself as a session cookie violation when the app server would receive the mq session cookie.

Comment 1

[Patrick McManus [:mcmanus]]

> Some of this behavior changed from FF9 to FF10 where it would confuse the
> page context and set the cookies from the MQ server into the web page
> context. This would manifest itself as a session cookie violation when the
> app server would receive the mq session cookie.

jason - thoughts? I'm 100% sure that I tested cookie behavior but maybe it regressed, maybe the wrong thing, or maybe there is some scenario I hadn't considered... it still needs to be confirmed, but certainly it shouldn't be doing what it described above.

Comment 2

[Andy Stevko]

Attachment: http headers log from testcase

I've created a test case to reproduce the observed behavior.
The test case is based on the tomcat trunk examples\websocket echo sample.
The last two request/response pairs are to two different hostnames.
Both are localhost, one is http at 2136 and the other is https at 2137.

Comment 3

[Andy Stevko]

Attachment: replacement for tomcat websocket example echo.html

place this into C:\tomcat\webapps\examples\websocket\echo.jsp

Comment 4

[Andy Stevko]

Attachment: replace websocket example EchoMessage with this proof

replace into this directory
C:\tomcat\webapps\examples\WEB-INF\classes\websocket\EchoMessage.java
This echos the cookies submitted to the client as a Message.

Comment 5

[Daniel Veditz [:dveditz]]

Cookies are not port-specific, they are scoped to the host rather than an origin (scheme-host-port tuple). Absolutely does not fit with anything else in the web's "same origin policy" mode, but we have to live with it.

Do you have an example that isn't using the same hostname for both sites?

Comment 6

[Jason Duell]

yes, I'm confused about the case you're tried here.  The report talks about using 

  Base web page - http://www.mysite.test/mywebapp
  Websocket url - http://stompeserver.mysite.test/stomp

In which case you should be able to isolate cookie (so long as you set domain to www.mysite.test, not the shared mysite.test base domain)

But the example session uses myapp.com for the hostname for both ws/http, in which case, as comment 5 notes, you get cookie sharing between the requests.

Comment 7

[Josh Aas]

Adding a temporary rating while we assess this.

Comment 8

[Jason Duell]

Stevko,

So are you seeing this with sites that differ by hostname, not just port?

Looking over the websocket code we defer all cookie handling to the HTTP stack, so if there's a bug here, it would probably be happening in HTTP too (and I'd guess we'd have heard about it already).

If we don't hear back, I'd suspect this is INVALID.

Comment 9

[Jason Duell]

Marking INVALID: no evidence that this affects other than same-domain, different port connections.