Hacker News Reader

Comment by tptacek | Hacker News Reader

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.

View on HN

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.

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

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

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

Yes.

Oracle padding

Reply on news.ycombinator.com