1) The attacker must be on the same network as you, or at least be able to detect how large the compressed and encrypted replies are.
If you are on the same network it seems to be there are far more MITM and whatnot attacks that are more likely to succeed, if you do not use HSTS (or secure DNS if that helps).
2) The attacker must be able to get your browser to rapidly generate many (how many?) requests from your browser to the site. It takes "30 seconds" they claim, but is that at a rate 100 requests per second?
3) Each request must carry something that will be reflected by the body of that particular page when it's rendered. I suppose it could be an error message or search string that's echoed.
It seems to me that unless you generate a CSRF token unconditionally on every page, the subset of pages that both reflect something with no protection (e.g. search results) and have a protected form (e.g. change my email address to XYZ) might be small.
4) The secret that can be extracted is what's in the reply body and not the headers -- headers are not compressed, since the TLS compression is now universally disabled post-CRIME.
Personally I use Referer header checking as well. IME all the browsers of my users do send them. So if you extract the CSRF token, it's useless by itself unless you also can make the browser send the right Referer header (and AFAIK, all the holes such as Flash have been plugged).
Other than that -- it seems that if you are normally generating e.g. a 32 byte CSRF key, you could interleave it with 32 bytes of good randomness per request?
>Personally I use Referer header checking as well. IME all the browsers of my users do send them. So if you extract the CSRF token, it's useless by itself unless you also can make the browser send the right Referer header (and AFAIK, all the holes such as Flash have been plugged).
This long comment boils down to "so this is an attack that negates the protection that TLS gives you in defending against CSRF attacks". Yes, in the CSRF case, that's what the attack is.
It takes "30 seconds" they claim, but is that at a rate 100 requests per second?
I took the 30 seconds to be the amount of compute time required after they had their samples. Otherwise it is a meaningless number, they could say it takes 0.5 seconds at a rate of 6k requests a second, or 3 thousand years at the rate of 1 request per year.
>Other than that -- it seems that if you are normally generating e.g. a 32 byte CSRF key, you could interleave it with 32 bytes of good randomness per request?
Which would be pretty easily averaged out with a few more requests. It makes the attack a little harder, but not substantially so.
One could argue that when talking about security, it's always about making things harder to breech, not a full proof protection..
I'm not sure how adding 32 bytes of "good randomness" would help.. because the size might be very similar since the randomness might not get properly reduced. And thus, the slight variation in size will still be very relevant.
However, adding between 1 and 32 bytes of randomness might be a pretty good counter! I.e. If you request the page with the "guess letter A", and then request again the same page with the same "guess letter A" and you get +/- 32bytes of different encrypted stuff, it's very hard to assume something was better compressed.
The cool thing about that is that it's fairly trivial to do with most implementation of CSRF. Thoughts?
The attacker just needs to work out the average size of the normal response, then the average size of the response with the extra character. Send enough requests and the difference will be noticeable. It slows them down, but doesn't fix the problem.
Regarding #1 and the other attacks that are more likely to succeed, are you referring to the propensity of users to bypass certificate warnings, or is there something else in play there?
Well, the certificate warnings have gotten pretty grave now, though I could imagine showing users an intermediate page telling them Microsoft has screwed up and you may get certificate warnings... which you should just ignore, trust us.
I was just thinking of hijacking DNS locally (i.e. when browser asks for yourbank.com, send them your IP), and making yourbank.com then redirect to yourbank.myfreehost.com -- which could have a legitimate SSL certificate and a copy of all the branding.
That seems more likely to succeed to me. I guess you could try BREACH if you have some high value target you know is using a very specific website. Anything bitcoin related: either the users themselves or admins. Robbing bitcoins is like robbing banks in the Wild West.
> Personally I use Referer header checking as well. IME all the browsers of my users do send them.
IME that is not true. Certain corporate/government machines have Referer headers turned off for some strange "security" reason. Last time I ran into this when working with Architect of the Capitol (http://www.aoc.gov/), when they couldn't log into a management panel because Django's CSRF protection checks the Referer header.
1) The attacker must be on the same network as you, or at least be able to detect how large the compressed and encrypted replies are.
If you are on the same network it seems to be there are far more MITM and whatnot attacks that are more likely to succeed, if you do not use HSTS (or secure DNS if that helps).
2) The attacker must be able to get your browser to rapidly generate many (how many?) requests from your browser to the site. It takes "30 seconds" they claim, but is that at a rate 100 requests per second?
3) Each request must carry something that will be reflected by the body of that particular page when it's rendered. I suppose it could be an error message or search string that's echoed.
It seems to me that unless you generate a CSRF token unconditionally on every page, the subset of pages that both reflect something with no protection (e.g. search results) and have a protected form (e.g. change my email address to XYZ) might be small.
4) The secret that can be extracted is what's in the reply body and not the headers -- headers are not compressed, since the TLS compression is now universally disabled post-CRIME.
Personally I use Referer header checking as well. IME all the browsers of my users do send them. So if you extract the CSRF token, it's useless by itself unless you also can make the browser send the right Referer header (and AFAIK, all the holes such as Flash have been plugged).
Other than that -- it seems that if you are normally generating e.g. a 32 byte CSRF key, you could interleave it with 32 bytes of good randomness per request?