5 ms·

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

by xs_kid 13y ago

beambot 13y ago
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...
- btilly 13y ago
  The first version of the attack, yes. But as http://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/ 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.
  - homakov 13y ago
    obviously second version (when CSRF token is stolen) is not possible to mitigate.
    - btilly 13y ago
      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.
      - homakov 13y ago
        XOR-based masking, yes, but I thought we were talking about currently common systems. Until BREACH nobody masked tokens, did they?
        btilly 13y ago
        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.
        homakov 13y ago
        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
- sdevlin 13y ago
  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 https://google.com/search?q=pajamas would become https://google.com/search?q=pajamas&csrf=etcetc 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.
- homakov 13y ago
  Django is vulnerable to cookie forcing. BREACH is not needed, CSRF token can be replaced with active MITM
jwilliams 13y ago
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.

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

by xs_kid 13y ago

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

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

btilly 13y ago
The first version of the attack, yes. But as http://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/ 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.
- homakov 13y ago
  obviously second version (when CSRF token is stolen) is not possible to mitigate.
  - btilly 13y ago
    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.
    - homakov 13y ago
      XOR-based masking, yes, but I thought we were talking about currently common systems. Until BREACH nobody masked tokens, did they?
      - btilly 13y ago
        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.
        homakov 13y ago
        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
sdevlin 13y ago
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 https://google.com/search?q=pajamas would become https://google.com/search?q=pajamas&csrf=etcetc 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.
homakov 13y ago
Django is vulnerable to cookie forcing. BREACH is not needed, CSRF token can be replaced with active MITM

jwilliams 13y ago

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.