Cross Site Request Forging (see http://en.wikipedia.org/wiki/Cross-site_request_forgery for more information) has been around for a while now. It misuses the trust of a web application that every request sent by the browser is wanted by its user.
Since the authors of our blog software are smart people, they implemented a CSRF protection. And not only them, even we not as smart PHProjekt developers implemented one.
There are three popular ways to protect your software against CSRF:
- using POST instead of GET
Another neat way to protect against CSRF, if there is no strange browser or proxy configuration that prevents the referrer header involved.
If the origin of a submission is from a different domain, don’t trust it.
- The token can be circumvented by a XHR request that reads the original form page and extracts the token form variable
- XmlHttpRequest.setRequestHeader(‚Referer‘, ‚http://targetdomain.com/spoofedreferer.php‘) allows you to set a fake header.
If you want to secure your application against CSRF, make sure that there are no XSS on your site, too.
Actually, turning Mayflower into a butchery wouldn’t change that much, you’d still be able to sell lots of Chorizo! :-)
Note that you can reintroduce huge security problems by improperly using crossdomain.xml, see http://shiflett.org/archive/267 for details.
That’s completely user-based, so I’m wary about implementing something like that. As you mention, you could end up accidently locking out users (esp those that may be covering their tracks by having configured their browsers never to send referer headers).
> make sure that there are no XSS on your site, too.
Easier said than done, especially for rich text input. For those of you looking for a good HTML filter, I’d recommend something I wrote: HTML Purifier (http://hp.jpsband.org/)
For crossdomain.xml: Yep, you could use it to shoot yourself in the foot even without having an XSS on your own site :-)
For your html-filter: i am pretty convinced that a whitelisting filter is the right way to go. Nevertheless i don’t believe in 100% security when html is involved.
But for sure i’ll have a look at it.
Like always, Stefan Esser found a way around this, using a different hostname for every form.
for more information.
Of course he is right, but the work to avoid csrf while being vulnerable to xss attacks is rather high. So somebody please come up with a version i can actually implement at customer sites!
yes referrer checks aren’t a good idea. people running norton internet security wind up blocking them by default it seems. i would never recommend using referrer checking, its bit me in the past.