Hacker News Reader

Comment by xs_kid | Hacker News Reader

There are any workaround for other web frameworks like Django or Padrino?

I'm not sure - but if you're concerned* you can turn off gzip compression for HTML. At least until a longer term fix is available. Turning off gzip/compression negates the attack irrespective of the framework.

* it's probably right to be concerned, but worth keeping in mind that this attack still requires a fair bit of access (to your traffic), planning (working out the vulnerable data) and intent.

I'm a bit confused.... In the mitigation section, the paper states: "However, we remark that requiring a valid CSRF token for all requests that reflect user input would defeat the attack."

Isn't that the point of CSRF? That's the advice Django provides anyway...

Typically CSRF tokens are only required for state-changing requests - POSTs, PUTs, DELETEs.

They're broadening that recommendation also to include pages that reflect input. Think GET requests that take query string parameters. So e.g. https://google.com/search?q=pajamas would become https://google.com/search?q=pajamas&csrf=etcetc.

It seems like a pretty impractical mitigation to me. For one thing, it would make it very difficult to share links; a link containing my CSRF token wouldn't work for you. It would also make it much easier to give up your CSRF token. We would need to retrain people to think of the URLs they're viewing as personal and secret.

The first version of the attack, yes.

But as http://arstechnica.com/security/2013/08/gone-in-30-seconds-n... makes clear, another variant lets you get the CSRF token, and after that the CSRF token is no protection at all against anything else that people try.

obviously second version (when CSRF token is stolen) is not possible to mitigate.

There is a way that the CSRF attack could be prevented. And that is if only every other byte of the CSRF token was part of the token, and the others were random every time.

In that case it would be impossible to predict common text in the CSRF based on past compression rounds.

XOR-based masking, yes, but I thought we were talking about currently common systems.

Until BREACH nobody masked tokens, did they?

Nobody did, but that is how life goes. An attack is found. A defense is found. And you can't build a secure system without knowing all of the attacks and corresponding defenses.

i wouldn't call it a proper defense, rather a work around. besides CSRF tokens there are lots of secret strings, and it's not website's problem to avoid wiretapping

Django is vulnerable to cookie forcing. BREACH is not needed, CSRF token can be replaced with active MITM

Reply on news.ycombinator.com