Hacker News Reader

Comment by Buge | Hacker News Reader

> fail to properly protect against unapproved cross-origin requests

It is not standard to block cross origin requests, in fact it rare or impossible in many cases.

It is standard to block cross origin requests that perform an action, usually a POST request.

But a GET request that just gets data is normally perfectly allowed cross origin. If I click a link from Google search results to the reddit homepage, that's a cross origin GET request, but reddit has to allow it, and recognize me as logged in. Also anything that could be embedded (such as an embedded Facebook comment box) would be required to allow cross origin GET requests.

View on HN

Your point is fair; you're entirely correct, but allow me to clarify mine. The existing CSP configuration on the 'unsuspecting' server will do one of two things:

[a] allow the cross-origin request to be made, in which case the malicious website could've just made the actual request instead and obtain the body of the actual response without any of this BEAST/CRIME trickery

[b] deny the cross-origin request, in which case there is no reflected data in the response, preventing the malicious website from performing the reflected data or data-comparison attack demonstrated in the paper

(If I'm wrong, what am I missing?)

As far as I know, if you do a regular GET or POST using XHR or the Fetch API, the server still replies with the full content, even with CORS blocking it - it's just that the browser doesn't let the fetching code read the actual content. That is, the CORS restriction is applied in the browser after the response has been sent, not in the server.

There is a preflight mechanism which the browser can use to avoid making the request at all, but that's only used for certain types of requests.

This. And even if the browser does block the request, the js probably sees that as an error code 0 (standard for cors) at which point it can use the performance timing apis.

Side channels are tough.

CSP isn't relevant. I suspect you want to talk about cors or origin headers or similar things, in which case you are missing that there's no need for a csrf vulnerability here - any GET with reflected data could do.

With this attack however doesn't the vulnerability depend on the attackers ability to see the size of the response to the Cross-Origin request?

So if the attackers JavaScript can't see a unique response it can't get the difference in size and can't execute the attack...

The attack determines the size based on the timing information returned by the Resource Timing APIs and the compression side-channel. This is described in section 2.2 of the paper.

They could use javascript to request the reddit homepage, and use TCP window stuff to see what the size was.

Reply on news.ycombinator.com