6 ms·

The techniques are interesting and clever, but isn't this "attack" only possible on websites that fail to properly protect against unapproved cross-origin reque

by niftich 10y ago

The techniques are interesting and clever, but isn't this "attack" only possible on websites that fail to properly protect against unapproved cross-origin requests, meaning they would be vulnerable anyway? I re-read the specs to make sure [1] but isn't it on the server to alter the response to potentially nothing if the cross-origin response didn't come from source the server expects? The paper says: "Similar to the defense of blocking 3rd-party cookies, the web server could also block requests that are not legitimate. A popular way of doing this, is by analysing the Origin and/or Referer request headers. However, it is still possible to make requests without these two headers, preventing the web server to determine where to request originated from. As a result, this technique can not be used to prevent attacks" On the contrary; the cross-origin access control spec (last edit in 2014) has an entire section on how to prevent malicious cross-origin requests like this, with verbiage like: "This extension enables server-side applications to enforce limitations (e.g. returning nothing) on the cross-origin requests that they are willing to service." If the server properly implements cross-origin access control by, say, returning nothing, the malicious cross-origin requesting script can't perform reflection attacks, and there's nothing interesting to measure with TCP windows and compression and the like. [1] https://www.w3.org/TR/access-control/ https://www.w3.org/TR/access-control/

lossolo 10y ago
Unless you have open redirection on one of your routes you are right. CSP is the answer. https://chloe.re/2016/07/25/bypassing-paths-with-open-redirects-in-csp/ https://chloe.re/2016/07/25/bypassing-paths-with-open-redire...
Buge 10y ago
> 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.
- niftich 10y ago
  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?)
  - icebraining 10y ago
    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.
    - dgoldstein 10y ago
      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.
  - dgoldstein 10y ago
    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.
- raesene6 10y ago
  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...
pfg 10y ago
The thing is: this attack doesn't even use CORS. It just sends a GET request to an URL and looks at the timing, which can be done using the fetch/Resource Timing APIs. Here's a JSFiddle to play around with this[1], based on the code in the paper, using GitHub's account page as an example. You'll notice that the request succeeds and the fiddle has access to timing information. Inspecting the requests will show that there are no CORS headers being sent (like Origin) based on which the target could prevent the request from being served. (There's the Referer header, I suppose, but blocking the request based on that would break pretty much any third-party link to that page.) I've tested this against various high-profile sites that include sensitive information (Google's account page, Twitter's account page, etc.), and it worked just fine on each of them. Most of them also have a parameter reflection vector (typically the full request URL is included somewhere on the page, which should be enough), so I'm pretty sure each of those sites are potentially vulnerable (though I'm not sure if calling a site vulnerable is the right approach here). [1]: https://jsfiddle.net/39rsn2kg/ https://jsfiddle.net/39rsn2kg/
- nine_k 10y ago
  Would inclusion of a small random timeout before serving the request solve this? Would not the load balancer activity cancel the effect? If anything, adding random garbage to the error page to approximately match the size of a normal response should make the attack useless.
  - pfg 10y ago
    Typical (WAN) network conditions are not all that different from a small random timeout, and these kind of attacks still work. Adding random noise just means you'll need more samples, but statistics are going to win eventually. I guess a combination of random noise and tight request rate limiting might mitigate this in practice (in exchange for a DoS vector, I suppose).
- turbohedgehog 10y ago
  What will break if the fetch/timing APIs are turned off in the browser?

by niftich 10y ago

lossolo 10y ago

Unless you have open redirection on one of your routes you are right. CSP is the answer. https://chloe.re/2016/07/25/bypassing-paths-with-open-redirects-in-csp/ https://chloe.re/2016/07/25/bypassing-paths-with-open-redire...

Buge 10y ago

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

niftich 10y ago
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?)
- icebraining 10y ago
  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.
  - dgoldstein 10y ago
    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.
- dgoldstein 10y ago
  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.
raesene6 10y ago
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...

pfg 10y ago

The thing is: this attack doesn't even use CORS. It just sends a GET request to an URL and looks at the timing, which can be done using the fetch/Resource Timing APIs. Here's a JSFiddle to play around with this[1], based on the code in the paper, using GitHub's account page as an example. You'll notice that the request succeeds and the fiddle has access to timing information. Inspecting the requests will show that there are no CORS headers being sent (like Origin) based on which the target could prevent the request from being served. (There's the Referer header, I suppose, but blocking the request based on that would break pretty much any third-party link to that page.) I've tested this against various high-profile sites that include sensitive information (Google's account page, Twitter's account page, etc.), and it worked just fine on each of them. Most of them also have a parameter reflection vector (typically the full request URL is included somewhere on the page, which should be enough), so I'm pretty sure each of those sites are potentially vulnerable (though I'm not sure if calling a site vulnerable is the right approach here). [1]: https://jsfiddle.net/39rsn2kg/ https://jsfiddle.net/39rsn2kg/

nine_k 10y ago
Would inclusion of a small random timeout before serving the request solve this? Would not the load balancer activity cancel the effect? If anything, adding random garbage to the error page to approximately match the size of a normal response should make the attack useless.
- pfg 10y ago
  Typical (WAN) network conditions are not all that different from a small random timeout, and these kind of attacks still work. Adding random noise just means you'll need more samples, but statistics are going to win eventually. I guess a combination of random noise and tight request rate limiting might mitigate this in practice (in exchange for a DoS vector, I suppose).
turbohedgehog 10y ago
What will break if the fetch/timing APIs are turned off in the browser?