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