Securing cross origin requests [CVE-2019-1000022]

[danielcompton]

From https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html, if somebody wasn't using CSRF tokens, it seems like it would be possible for any malicious website to open up a web socket to do Bad Things. I know that CSRF tokens are highly recommended, but they're not suitable for all cases (I think). It could be good to also add CORS style protection to Sente to allow only whitelisted origins. What are your thoughts?

N.B. CORS itself has no influence on websocket connections.

[danielcompton]

From the article:

As a Pentester
Check for Cross-Site WebSocket Hijacking attacks as soon as you notice any WebSocket based communication in the application you're analysing. As a side note, in case you already find Origin header verification present in the application, try to bypass it from victim's browser: When the server expects https://www.some-trading-application.com as the Origin, mount your attacks on https://www.some-trading-application.com.some-evil-attacker-application.com to test for obviously broken Origin header verifications.

As a Security Consultant
Make your clients aware of the requirement to always check Origin headers. Educate them to secure all WebSocket handshakes using random tokens (like protecting against CSRF attacks) or let them embed the authentication and/or authorization into the WebSocket protocol (avoid web session access).

As a Developer
Make sure you are aware of this attack scenario and know how to employ the countermeasures securely into your application (at least when you need to access the web session from the application part that uses WebSockets or when you otherwise try to transfer non-public data over that channel). Better try to avoid accessing the web session from the server-side WebSocket counterpart and separately handle authentication and/or authorization using tokens or similar techniques within your WebSocket protocol.

[ptaoussanis]

Hi Daniel,

I know that CSRF tokens are highly recommended, but they're not suitable for all cases (I think).

First step would be suggesting a use case where they're not suitable so that we know what we're talking about exactly (why they're unsuitable in this case, etc.).

It could be good to also add CORS style protection to Sente to allow only whitelisted origins. What are your thoughts?

Is there a reason you wouldn't want to be using Content Security Policy for this?

[danielcompton]

I think CSP is exactly what I was looking for for this. It looks like connect-src is the appropriate policy.

UPDATE: ^^This is incorrect, I was mistaken in my understanding of what CSP provided.

[danielcompton]

Actually, I think that it might still be important to check Origin headers too, but I need to think about this.

[ptaoussanis]

Okay to close this?

[danielcompton]

Sure, for now. I may revisit this in the future.

[awkay]

So, I'm in the process of a security review on code for a consulting client, and I'm looking at websockets.

I've looked at the Sente code now for a couple of hours, and I cannot see how the current implementation is secure. Worse, it looks to me like it is providing a way for an attacker to actually obtain the CSRF token, since sente sends it as part of the handshake...all an attacker needs to do, it seems to me, is know that sente is in use, emulate the handshake logic, and now the attacker not only knows the CSRF, but they can hijack the websocket for a fully async "authorized" communication channel.

My understanding is that CSRF only works if the secret is embedded into the HTML (because js cannot request HTML pages cross-origin) and manually transferred into the js network request back to the server. If it can be "queried" by js with nothing but a cookie as backup, then the security is broken.

I did read your example, and it is true that requiring a user to auth after the connection is established is the "gold standard" (assuming you require they type a password), but that requires the user to log in again if they reload the page (or temporarily lose the network connection).

As far as I can tell the current CSRF logic basically just gets you "around" the anti-forgery middleware denying requests...it doesn't actually provide any real security, and I do think it actually compromises the anti-forgery protections on "other" POSTs.

Perhaps you intended for users of the library to implement their own security around this (which might be the case...it requires HTML twiddling that sente cannot do, and origin checks that would require more config).

I'm putting this in this closed issue because there is some chance I've misunderstood something.

If not, I'd recommend removing the CSRF from the handshake, and documenting that it has to be passed through the HTML as a parameter given to sente on the client. E.g. the HTML serve would embed a js var or something into the head of the page, and cljs would read that var to set the option for sente.

[eerohele]

(Disclaimer: I'm not a security professional.)

I've spent the last couple of days looking into WebSocket security and I'm mostly left confused.

I don't understand how Sente's anti-CSRF token implementation protects from CSRF attacks. (It might work when using the Ajax long-polling bits of Sente — I haven't looked into that part because I don't use it myself).

For example, say I have a web app at https://foo.com and I've logged into it with my browser. Sente is listening in at wss://foo.com/chsk. The web app also has the Ring anti-forgery middleware correctly configured, which means Sente can use the anti-CSRF token.

I then open another tab in the same browser and type this into the browser's Developer Console:

var ws = new WebSocket("wss://foo.com/chsk?client-id=foo")

ws.onmessage = function (event) {
  console.log(event.data);
}

Because the WebSocket connection is not subject to the Same-Origin Policy, I can open the connection successfully. The session cookie is passed along with the WebSocket connection request, which means authentication isn't required. The anti-CSRF token Sente uses seems to have no effect.

Embedding the anti-CSRF token into the HTML might be better than the current situation, but I don't see how even that would currently prevent CSRF attacks, seeing as Sente doesn't actually seem to require the anti-CSRF token to establish a WebSocket connection. Also, it seems to me that if we did that, we'd be using the anti-CSRF token as a kind of an authorization mechanism, which isn't what the anti-CSRF token is for.

I don't really see how the anti-CSRF token is relevant for WebSocket requests, but it's entirely possible that I'm missing something.

With regard to CSP: I've seen recommendations to add the Content-Security-Policy: connect-src 'self' header into the server response. For example, this Gist says that [the header] "prevents webSockets requests from any place but the current server. "

That's not true, however. As I understand it, a content-security policy basically says:

While you're on this site, you're only allowed to load resources from these sources.

In other words, with WebSockets, if your CSP is connect-src 'self', while you're on https://foo.com, you're only allowed to connect to a WebSocket server running on https://foo.com. The CSP disallows connections to WebSocket endpoints in any other URLs. If you're on http://attacker.com, though, a CSP on https://foo.com has no effect on anything you do.

So, if https://foo.com has an XSS vulnerability that an attacker uses to try to connect to a WebSocket endpoint elsewhere (e.g. to display misleading information to the user or something like that), the `connect-src 'self' CSP would prevent that.

As I see it, a CSP does not protect the user from CSRF attacks — at least with regard to WebSockets.

The only thing that I'm aware of that protects the user from CSRF attacks targeting WebSocket endpoints is to check that the value of the Origin header matches the current domain in the WebSocket handshake route handler (which is what @danielcompton proposed earlier).

For example, a Ring middleware for https://foo.com would look something like this:

(defn wrap-ensure-origin
  [handler]
  (fn [request]
    (if (= (get-in request [:headers "origin"]) "https://foo.com")
      (handler request)
      {:status 403
       :body   "Forbidden"})))

You'd then wrap that middleware around Sente's ring-ajax-get-or-ws-handshake handler.

If your app runs on multiple different domains, you'll unfortunately have to add the domain names in your app's configuration. That means that the best thing Sente can do is to advise users to add middleware that checks the Origin header into their web apps, I think.

That's my understanding of the whole picture. I'm hoping someone will correct me if I'm wrong on something — I'm learning as I go here.