Preventing CSRF and XSRF Attacks

In Cross-Site Request Forgeries and You I urged developers to take a close look at possible CSRF / XSRF vulnerabilities on their own websites. They're the worst kind of vulnerability -- very easy to exploit by attackers, yet not so intuitively easy to understand for software developers, at least until you've been bitten by one.

This is a companion discussion topic for the original blog entry at:

Sounds like a good reason for security wingnuts to finally start accepting cookies

Can we PLEASE add an HTTP header to indicate image and other embeded requests? While it wouldn’t prevent all XSRF attacks, it’d certainly go a long way to putting some sanity in the img tag.

Of course form value and the cookie value are the same should not be taken literary, but as:

X - form value,
C - cookie value
bool F(X,C) - validation function, which can be as simple as X == C, or as complicated as you wish F(X,C) = F3(F1(X), F2©)

Not just forms. Any Ajax request should also contain a pseudo-random value (I think it’s called a nonce)

I’d rather we spent time on tougher laws for punishing people that exploit the perpetually weak internet, than waste time plugging every hole in the sinking ship. The fact that there’s jail time involved in break enter lets me sleep far more soundly than the shiny new locks and bulletproof doors I just installed in my home.

But then again, I guess everyone is responsible for protecting their own interests.

Hey I’m from Canada, where everyone loves everyone and we didn’t invent the internet.

Over the last 3 weeks I’ve read a number of posts regarding CSRF attacks. It’s the first time I’ve heard of them. Luckily, I’m about to start a personal project for a government department which maintains information for approx 10,000 disabled clients.

I don’t think they’d appreciate too much exposing the names and addresses of that many vulnerable people.

This just highlights that there is SO much developers need to be aware of. Especially those just out of Uni beginning their career. It isn’t just a simple application with a login form and CRUD operations. There’s major security concerns. User validation. Data validation. Data security. Control flow checks. What would take 1 or 2 weeks as a school assignment can take 6 months to do properly and securely.

I want to vote this post up :slight_smile:
not addicted at all…

That is the best explanation I’ve ever read of them.

Amen to mandatory cookies, but there are a whole lot of people out there who have been told that cookies are bad, mmmkay, and just won’t budge. Their brother in law, who knows enough to get their printer unjammed, told them so.

No problem with adding toolbars to their browsers because they get free email smileys though…

@David: if you’re performing actions in response to GET requests, you’re doing it wrong. It’s not just a matter of security–you’ll end up with Google Web Accelerator deleting your site ( ).

See for the One True HTTP interaction model.

Sounds like a good reason for security wingnuts to finally start accepting cookies.

No, because its the cookie that authenticates the browser and not the user. CSRF attacks cannot be accomplished without the cookie. If you keep no cookies, you cannot be targeted.

@Jason: Yes, browser cross-site restrictions prevent access to most content from another domain–they can submit a form they create to your handler, and they can currently make the user click on a form in an iframe ( ), but they can’t read or modify content from another site. The notable hole in these policies at the moment is JSON/Javascript interception, which can be prevented by requiring pre-execution processing. ( )

Do not implement users on your web app. Period.

I’m the first one at being mistaked Oh, the irony XD

Maybe someone can help me out; just for my own benefit.

What, specifically, would it take to fall victim to a CSRF/XSRF attack; from the perspective of a user?

I’d need to log into a particular website, like the where I’ve got an account. Once I’ve already authenticated with that site, and while that session is open/established; I’d need to visit another website - one that was intentionally designed (or intentionally hacked) to exploit the exact website I also had visited (

Is my understanding correct?

I’m all for websites being secure - but this seems to be ‘unlikely to happen’ in a real-world environment. Maybe I’m being naive? As someone who really only visits reputable sites, it would take a malicious hacker compromising a major website (like Google) and then writing the code to exploit a large number of websites that are vulnerable to CSRF/XSRF attacks in the hopes of my having an active session/being logged in to, that particular website?

Is my understanding correct?


this seems to be ‘unlikely to happen’ in a real-world environment. Maybe I’m being naive?

Depends. Phishing is a huge problem, and Phishing + XSRF is a very real threat. Also, a lot of sites are allowing user generated content in comments, wikis, things like that. If you can post a link, other users of that site WILL click on it. And if that link points to an HTML page containing XSRF exploit on the site…

It’s really not very hard at all to imagine many, many effective XSRF attacks.


  • What evidence do you have that more punishment has a correlation with lower crime rates?
  • The internet is global, and your laws are likely irrelevant where the attacker live.

Revenge is always too late.

At last! A clear concise explanation about why everyone is getting their panties all wadded up over this issue!

So, if I have a YouTube login, and a login cookie on my browser, I could go to another website. That website could request a YouTube URL that uses my browser’s cookie for authentication. Now it finally makes sense.

That really makes the use of cookies for authorization is really a no-no. That does eliminate a big convenience: Visiting a website without having to log in each and every time.

A quick question: How about the session value used heavily by PHP? Is that also browser based?

What I don’t understand is why we aren’t made at the browser manufacturers. Why are browsers sending cookies when a logical session no longer exists? It’s hard to wrap my head around this concept so here is an example.

  1. I go to through my browser. The browser caches a cookie.
  2. I surf for 10 minutes to some random sites.
  3. I go to some nasty site that contains a CSRF for and my browser sends the cookie from #1 above simply because it is the same domain.

Why? Surely my browser is smart enough to sandbox these things. It knows that I went to site #3 separately. Maybe in some rare cases the forger may find a way to get his site into the browsing pattern so that it isn’t quite as clear. But 99% of the time the browser knows thta you’ve visited a separate page. Why would it send a cookie from a completely unrelated browsing session?

Again, this seems like it COULD be solved by browsers and the laxed cookie handling that browsers use is mainly to blame. Or am I missing something? Again, I’m not talking about a 100% solution. But we could probably make browsers even slightly smarter and nip this thing in the bud immediately.

Matt, the problem isn’t strictly the browser. Imagine that ING Direct allows you to comment on a stock (say in a forum). If I can do that and the site allows me to post HTML of some kind (say to include formatting or links) then you might run afoul of cross-site scripting. It doesn’t matter if you click on my link or not, but if the site isn’t coded to prevent all the various forms of XSRF attacks just visiting it can cause my script to run and take some action on your behalf.

Even if it prevents that, I might post a link that you think you want to click on (like a CNN article maybe), but of course goes to my page first in order do something nefarious before passing you along to the purported destination.

It’s an insidious problem and not one the browsers can easily solve. Rich internet applications make extensive use of cookies…

Great post, one point though, I’ve seen a fair number of people over-react to CSRF and implement a solution that breaks the back button or using the site from multiple tabs.

You mention that you:

to generate (and track, with timeout) a unique random key for every single HTML FORM you send down to the client.

I think it would help to explain how you verify that the token is correct. The naive solution where the most recently generated token is the only valid token breaks the back button (since it has a form with a previous token) and also tabbed browsing.

Also, what does generating a fresh token with each request gain for you? If you suspect an attacker can grab the token when they see the request why would the attacker not just grab your cookie so they can take complete controller over your session.

Understanding how the addition token add secure is important since developers are currently rolling their own solution.

Twitter for many months had their own solution that broke the back button and tabbed browsing. They claimed changing the only valid token with each request made the system more secure, but in reality it broke the browsing experience with no added security.