Session ID in URL Rewrite

[kumangxxx]

You want to:

• report a bug
• request a feature

Current behaviour

socket.io will add ?sid= to the url when trying to connect

Steps to reproduce (if the current behaviour is a bug)

Normal use of socket.io client for javascript

Expected behaviour

Can we move the sid to header ?

Other information (e.g. stacktraces, related issues, suggestions how to fix)

Context:
We ran penn test against our socket app using ZAProxy. One of the alert we got is this:

Session ID in URL Rewrite:
URL rewrite is used to track user session ID. The session ID may be disclosed via cross-site referer header. In addition, the session ID might be stored in browser history or server logs.

adding sid to url is problematic according to zaproxy.

my url is like this:

http://localhost:3000/socket.io/?channel=widget&EIO=3&transport=websocket&sid=0JfeAmWw8EceWQkTAAAA

can someone explain the security risk if someone can get other people's sid ?
can it be used to listen/publish or get older messages ?
can we move the sid to Header ?

thanks

[gasnier]

I have the same problem and same questions...

[yangpu]

I got the security report of "Session ID sent in URL Rewrite":

URL rewrite is used to track user session ID. The session ID may be disclosed via cross-site referer header. In addition, the session ID might be stored in browser history or server logs.

and recommendation:

For secure content, put session ID in a cookie. To be even more secure consider using a combination of cookie and URL rewrite.

Any help is appreciated.

[IllusionVK]

@kumangxxx @yangpu @gasnier did anyone look at https://www.npmjs.com/package/socketio-auth and did it help ?

[Tapojit]

To be even more secure consider using a combination of cookie and URL rewrite.

The last line of the recommendation is key. I think it's best practice you ensure cookie with sid is set alongside the sid in url rewrite. You can enable cookies according to this example:
https://socket.io/docs/v3/handling-cors/

[nesh-ua]

any news?

[darrachequesne]

To shed some light on this:

can someone explain the security risk if someone can get other people's sid?
can it be used to listen/publish or get older messages ?

If the client is in HTTP long-polling mode, if you have access to the sid, you can indeed publish messages on behalf of the user.

Reproducible example:

const socket = require("socket.io-client")("http://localhost:3000", {
  transports: ["polling"]
});

socket.on("connect", () => {
  console.log(socket.io.engine.id); // prints something like "l9IoONULqVPQYa0DAAAA"
});

And then run:

curl -X POST "http://localhost:3000/socket.io/?EIO=4&transport=polling&sid=l9IoONULqVPQYa0DAAAA" -d '42["event"]' -v
< HTTP/1.1 200 OK
< Content-Type: text/html
< Content-Length: 2
<
* Connection #0 to host localhost left intact
ok

You can't read messages though, as the connection will be closed (only one read request is accepted per connection):

curl -X GET "http://localhost:3000/socket.io/?EIO=4&transport=polling&sid=l9IoONULqVPQYa0DAAAA" -v
< HTTP/1.1 500 Internal Server Error
<
* Connection #0 to host localhost left intact

If the client is connected with WebSocket, any HTTP request with the given sid will be denied:

curl -X POST "http://localhost:3000/socket.io/?EIO=4&transport=polling&sid=l9IoONULqVPQYa0DAAAA" -d '42["event"]' -v
< HTTP/1.1 400 Bad Request
< Content-Type: application/json
<
* Connection #0 to host localhost left intact
{"code":3,"message":"Bad request"}

can we move the sid to Header?

We could indeed move the sid to the request headers for HTTP long-polling, but that wouldn't work for WebSocket, as the WebSocket browser API does not allow for custom headers.

[darrachequesne]

Closed due to inactivity, please reopen if needed.