5 ms·

CSRF: Cross-Site Request Forgeries

35 points by huntern 14y ago

DanielRibeiro 14y ago
Google also did a very good job introducing security vulnerabilities, and also a sandbox for trying them out. Their take at Cross-Site Request Forgery: http://google-gruyere.appspot.com/part3#3__cross_site_request_forgery http://google-gruyere.appspot.com/part3#3__cross_site_reques... The sandbox: http://google-gruyere.appspot.com/start http://google-gruyere.appspot.com/start
smcl 14y ago
Is it displaying as grey text on a brown background for everyone else? That's nigh-on unreadable edit: maybe not grey but some colour which doesn't contrast with brown at all
- sim0n 14y ago
  It's brown on white as long as all the images load.
  - smcl 14y ago
    Ah there we go, I didn't think to refresh :/ One of those days
- jamessocol 14y ago
  Ugh, I really need to create a lighter-weight theme. Sorry about that.
  - smcl 14y ago
    Nope it was just me being an idiot :)
mrfu 14y ago
* These are submitted with a form (over POST, hopefully) * I don't think that the author implies that using POST prevents CSRFs but the article seems to imply it. In case anyone thinks it is the case: using POST won't prevent a CSRF. Cross Site Request Forgeries occur when a user opens an "evil" page on site B, while being logged on site A. If site A solely relies on cookies in order to identify logged users, there is a risk of CSRF. The attack exploits the fact that the user's browser will always send the auth cookies when issuing a request to siteA. If the evil page on siteB embeds an image (or script, or any resource that can be loaded using an URL) whose source is an URL on siteA, the browser will request the resource on siteA with the auth cookie coming along. In order to issue a POST request to siteA from the evil page, the attacker only has to submit a crafted POST form using an iframe.
- jamessocol 14y ago
  > In order to issue a POST request to siteA from the evil page, the attacker only has to submit a crafted POST form using an iframe. Yes, but requiring POST for anything that changes anything (especially bank transfers) is a best practice anyway, for how all actors involved understand HTTP verbs, and reduces the surface area of attack. You can create a POST with an iframe, but you can create a GET with an image tag: `<img src="http://mybank.com/transfer?...>` http://mybank.com/transfer?...>`
- jamessocol 14y ago
  I updated the post to point this out.
ericmoritz 14y ago
Perhaps I'm just nieve but if someone has access to the DOM via XSS; isn't CSRF nonces like Django uses pointless?
- jamessocol 14y ago
  Hopefully you're taking steps to prevent both. But yes, closing the CSRF window and leaving the XSS door open would largely defeat the purpose of CSRF protections.
- adrr 14y ago
  If you have XSS attack vector on your site, the attacker can do almost anything including cookie access(for all cookies that aren't HttpOnly). Also CSRF protection doesn't protect against clickjacking attacks where the page is iframed set transparent and user is encouraged to click in a specific location(punch the monkey in the face) on the attackers page. Easiest solution is to use javascript to detect if your page is iframed and bust out of it.
  - jamessocol 14y ago
    For click-jacking, the easiest thing to do is to set the X-Frame-Options header, but I'll get to that. And it doesn't help IE <= 7, so you need to weigh cost/benefit and your user base there. And we'll get to session hijacking and why your session cookies in particular should always be HttpOnly and preferably secure.
    - adrr 14y ago
      Thanks for the info, didn't know about the header.
- david_shaw 14y ago
  I understand your question, and in many ways you're correct; that said, let's say you have stored XSS in some obscure parameter of your web application. One way to exploit the Victim via XSS would be to convince them to browse to the compromised section of the site. Sometimes, that's as simple as getting them to click on a malformed URL -- basically, the same vector as getting them to click on your CSRF-ized link, anyway. Many applications, however, don't have direct URLs to certain areas of the app. It could be hidden by Javascript/AJAX population, or written in a language/framework that doesn't support that kind of direct linking. Therefore, if some kind of sensitive function is easily owned by CSRF (say, account.php?sendto=Eve), but the XSS is stored someplace obscure that might not be available via public URL (browse to Accounts -> Details -> My Bio, which populates dynamically), the higher threat severity would be the CSRF. Sorry this turned kind of long, but I deal with a lot of webapp security issues on a day-to-day basis and feel relatively qualified to answer this one in some depth :)
psychotik 14y ago
A simple explanation for the non tech folks: http://crazyviraj.blogspot.com/2009/10/xsrfcsrf-attacks-in-non-geek-speak.html http://crazyviraj.blogspot.com/2009/10/xsrfcsrf-attacks-in-n...
zeroonetwothree 14y ago
One thing that's not covered by a lot of frameworks is protecting against CSRF in AJAX requests. Django has some info on enabling this (https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax), but it's easy to overlook.
- jamessocol 14y ago
  Honestly, "easy to overlook" is why I wrote a checklist for basics. CYA, then get to the advanced stuff.
languagehacker 14y ago
This is a decent article, but it's really just another "use your framework to mitigate CSRF" article. There's probably been hundreds of them in the last five years. Useful for junior devs who haven't seen it before; uninteresting for most everyone else.
- jamessocol 14y ago
  We keep making more junior devs. It's important to drown out the w3schools and bad practices with good practices, so when they look up how to do it, they learn the right way.
- chao- 14y ago
  Speaking as someone who is still, arguably, a "junior dev", and who started reading Hacker News as a far-more-junior dev, getting these topics on your radar has to happen somehow. I've learned about many topics' existence by simply bumping into articles like this, and checking the comments to learn more. I do agree the article is little more than introductory, but rather than complain, let's provide some more in-depth links for those who want to learn: http://www.slideshare.net/guestdb261a/csrfrsa2008jeremiahgrossman-349028/ http://www.slideshare.net/guestdb261a/csrfrsa2008jeremiahgro... http://appsandsecurity.blogspot.com/2012/01/stateless-csrf-protection.html http://appsandsecurity.blogspot.com/2012/01/stateless-csrf-p...

35 points by huntern 14y ago

Google also did a very good job introducing security vulnerabilities, and also a sandbox for trying them out. Their take at Cross-Site Request Forgery: http://google-gruyere.appspot.com/part3#3__cross_site_request_forgery http://google-gruyere.appspot.com/part3#3__cross_site_reques... The sandbox: http://google-gruyere.appspot.com/start http://google-gruyere.appspot.com/start

smcl 14y ago

Is it displaying as grey text on a brown background for everyone else? That's nigh-on unreadable edit: maybe not grey but some colour which doesn't contrast with brown at all

sim0n 14y ago
It's brown on white as long as all the images load.
- smcl 14y ago
  Ah there we go, I didn't think to refresh :/ One of those days
jamessocol 14y ago
Ugh, I really need to create a lighter-weight theme. Sorry about that.
- smcl 14y ago
  Nope it was just me being an idiot :)

mrfu 14y ago

* These are submitted with a form (over POST, hopefully) * I don't think that the author implies that using POST prevents CSRFs but the article seems to imply it. In case anyone thinks it is the case: using POST won't prevent a CSRF. Cross Site Request Forgeries occur when a user opens an "evil" page on site B, while being logged on site A. If site A solely relies on cookies in order to identify logged users, there is a risk of CSRF. The attack exploits the fact that the user's browser will always send the auth cookies when issuing a request to siteA. If the evil page on siteB embeds an image (or script, or any resource that can be loaded using an URL) whose source is an URL on siteA, the browser will request the resource on siteA with the auth cookie coming along. In order to issue a POST request to siteA from the evil page, the attacker only has to submit a crafted POST form using an iframe.

jamessocol 14y ago
> In order to issue a POST request to siteA from the evil page, the attacker only has to submit a crafted POST form using an iframe. Yes, but requiring POST for anything that changes anything (especially bank transfers) is a best practice anyway, for how all actors involved understand HTTP verbs, and reduces the surface area of attack. You can create a POST with an iframe, but you can create a GET with an image tag: `<img src="http://mybank.com/transfer?...>` http://mybank.com/transfer?...>`
jamessocol 14y ago
I updated the post to point this out.

ericmoritz 14y ago

Perhaps I'm just nieve but if someone has access to the DOM via XSS; isn't CSRF nonces like Django uses pointless?

jamessocol 14y ago
Hopefully you're taking steps to prevent both. But yes, closing the CSRF window and leaving the XSS door open would largely defeat the purpose of CSRF protections.
adrr 14y ago
If you have XSS attack vector on your site, the attacker can do almost anything including cookie access(for all cookies that aren't HttpOnly). Also CSRF protection doesn't protect against clickjacking attacks where the page is iframed set transparent and user is encouraged to click in a specific location(punch the monkey in the face) on the attackers page. Easiest solution is to use javascript to detect if your page is iframed and bust out of it.
- jamessocol 14y ago
  For click-jacking, the easiest thing to do is to set the X-Frame-Options header, but I'll get to that. And it doesn't help IE <= 7, so you need to weigh cost/benefit and your user base there. And we'll get to session hijacking and why your session cookies in particular should always be HttpOnly and preferably secure.
  - adrr 14y ago
    Thanks for the info, didn't know about the header.
david_shaw 14y ago
I understand your question, and in many ways you're correct; that said, let's say you have stored XSS in some obscure parameter of your web application. One way to exploit the Victim via XSS would be to convince them to browse to the compromised section of the site. Sometimes, that's as simple as getting them to click on a malformed URL -- basically, the same vector as getting them to click on your CSRF-ized link, anyway. Many applications, however, don't have direct URLs to certain areas of the app. It could be hidden by Javascript/AJAX population, or written in a language/framework that doesn't support that kind of direct linking. Therefore, if some kind of sensitive function is easily owned by CSRF (say, account.php?sendto=Eve), but the XSS is stored someplace obscure that might not be available via public URL (browse to Accounts -> Details -> My Bio, which populates dynamically), the higher threat severity would be the CSRF. Sorry this turned kind of long, but I deal with a lot of webapp security issues on a day-to-day basis and feel relatively qualified to answer this one in some depth :)

psychotik 14y ago

A simple explanation for the non tech folks: http://crazyviraj.blogspot.com/2009/10/xsrfcsrf-attacks-in-non-geek-speak.html http://crazyviraj.blogspot.com/2009/10/xsrfcsrf-attacks-in-n...

zeroonetwothree 14y ago

One thing that's not covered by a lot of frameworks is protecting against CSRF in AJAX requests. Django has some info on enabling this (https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ajax), but it's easy to overlook.

jamessocol 14y ago
Honestly, "easy to overlook" is why I wrote a checklist for basics. CYA, then get to the advanced stuff.

languagehacker 14y ago

This is a decent article, but it's really just another "use your framework to mitigate CSRF" article. There's probably been hundreds of them in the last five years. Useful for junior devs who haven't seen it before; uninteresting for most everyone else.

jamessocol 14y ago
We keep making more junior devs. It's important to drown out the w3schools and bad practices with good practices, so when they look up how to do it, they learn the right way.
chao- 14y ago
Speaking as someone who is still, arguably, a "junior dev", and who started reading Hacker News as a far-more-junior dev, getting these topics on your radar has to happen somehow. I've learned about many topics' existence by simply bumping into articles like this, and checking the comments to learn more. I do agree the article is little more than introductory, but rather than complain, let's provide some more in-depth links for those who want to learn: http://www.slideshare.net/guestdb261a/csrfrsa2008jeremiahgrossman-349028/ http://www.slideshare.net/guestdb261a/csrfrsa2008jeremiahgro... http://appsandsecurity.blogspot.com/2012/01/stateless-csrf-protection.html http://appsandsecurity.blogspot.com/2012/01/stateless-csrf-p...