

CSRF: Cross-Site Request Forgeries - huntern
http://coffeeonthekeyboard.com/csrf-cross-site-request-forgeries-basic-security-part-3-747/

======
DanielRibeiro
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_reques...](http://google-
gruyere.appspot.com/part3#3__cross_site_request_forgery)

The sandbox: <http://google-gruyere.appspot.com/start>

------
mrfu
* 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
> 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?...>`)

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

~~~
chao-
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/csrfrsa2008jeremiahgro...](http://www.slideshare.net/guestdb261a/csrfrsa2008jeremiahgrossman-349028/)

[http://appsandsecurity.blogspot.com/2012/01/stateless-
csrf-p...](http://appsandsecurity.blogspot.com/2012/01/stateless-csrf-
protection.html)

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

------
zeroonetwothree
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>), but it's
easy to overlook.

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

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

~~~
jamessocol
Ugh, I really need to create a lighter-weight theme. Sorry about that.

~~~
smcl
Nope it was just me being an idiot :)

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

~~~
adrr
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
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
Thanks for the info, didn't know about the header.

