[z-factor]

The attacker has to be able to issue requests on behalf of the user with injected "canary" strings. I fail to see a practical exploit where one can do this and wouldn't have access to the secret in the response anyway. What am I missing?

[tptacek]

Does any GET or POST URI endpoint in your application accept parameters? Do none of those parameters impact the output of the application? That set of circumstances is extraordinarily common.

[z-factor]

The request has to be issued by the attacker from the victim's browser. If the attacker can do that, why is he unable to read the response to that request?

Edit: I think I can see a scenario where a third-party website does these requests via an <iframe> or an <img>. I'm not sure there's a way to do POST quite as easily.

[tptacek]

Do you understand how CSRF works? Just think of it in terms of CSRF. Since the attacker is trying to infer page content, they don't care that the server rejects all the probing requests, so CSRF protection doesn't help you as the attacker carries out the BREACH/CRIME stuff. If the result of the attack is an inferred CSRF token, they then cap the whole exploit off with a (now working) actual CSRF attack.

[z-factor]

I understand how the attack works, the question was about how a practical exploit would actually be carried out. I've figured out how one would issue GET requests from the right environment, but I don't know if the same is possible for POST.

[wglb]

It is just as possible. POST csrf exploits add between two and three minutes to an attacker to craft the request differently.

[tptacek]

Just in case you weren't clear on this already: CSRF works just fine against POST endpoints. Think Javascript.

[chopin]

Would it be possible to thwart this attack (BREACH) by issuing fresh CSRF tokens for each requests?

[z-factor]

Yes.

[homakov]

Oracle padding

[veesahni]

I'm in the same boat - if the attacker could inject strings into requests pre-compression, then wouldn't the client already be compromised?

[rlucas]

No, you're missing that the original GET requests can be performed in some cases over HTTP, either by forgery or by surreptitiously spoofing the user's own browser into doing it. No need to have compromised the SSL/TLS.