Example

This is about a kind of XSS security hole betterworld and I detected recently.It's described at http://en.wikipedia.org/wiki/Cross-site_request_forgery You have a webapp at yourdomain.example. Let's say you have a profile settings site where you can set your realname, for example (harmless example though).

The user is authenticated by a session cookie.

The form looks like this:

if ($cgi->param('submit.save_realname')) { my $name = $cgi->param('realname'); # do some checks on $name $user->realname($name); $user->update; } [download]

The code looks like:

Looks fine, doesn't it?

Missed something?

The form-method is POST. Why is it POST and why don't you care in the script if it really was sent by POST?Consider some bad hacker creates a website on http://somewhere.example/bad.html:Now if you are logged in at your website (have a cookie) and somehow go to the bad website, your realname will be set automatically, and you canot do anything to prevent this. You don't even need Javascript.

An easy solution for this is to check for POST in your application.

if ($cgi->request_method() eq 'post')

(Bad thing is, there are a lot of websites out there that don't check, and while you can make your own applications safe, you can't do this for other sites you visit)

Still not safe?

Use Tokens

<input type="hidden" name="t" value="123abc...">

Couldn't browsers help me to surf more secure?

Well, consider you have Javascript on. The bad website could look like this:Here checking for POST will not help you (as a user). The only thing that helps is to have Javascript off for unknown websites (Site preferences in Opera, NoScript in FF). And hope that the bad html-form is not on a website where you have Javascript on.A lot of websites do this already; create a token (that expires like a session-id), and that must be a parameter in the form:So every action of the script that changes data should require such a token. That makes your script pretty safe.Well, if the scripts are programmed badly, why should browser vendors care?Because they can.

In Opera you can say that you just want get cookies from the current site. Unfortunatley Opera still sends cookies from domain A to an embedded image of domain B.

In Firefox you can say "Privacy - Cookies - from original site only", which will prevent receiving and sending cookies.

But even the Firefox preference does not prevent doing a meta-refresh.

Also, there is no possibility to say "Warn me before a site does a form.submit() to a different domain". All these things could be implemented.

So, while you can do some things to make your own scripts safe, do you also think, browsers should take care of these issues? Here is a posting on Bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=375238 about this.

Update 2008-04-17: In Opera 9.5 the option "only send cookies to the site I visit" works reliably. In Firefox, the extension CookieSafe (and the option originalOnly) doesn't work reliably. So if you wanna be safe from CSRF, try Opera 9.5. But make sure you deactivate this option for OpenID sites.