Re: Is your web application really secure? ("CSRF")

[betterworld]

in reply to Is your web application really secure? ("CSRF")

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:
<input type="hidden" name="t" value="123abc...">
So every action of the script that changes data should require such a token. That makes your script pretty safe.

I do agree that embedding the session id or a token into the HTML code is currently the most secure and portable way to avoid XSRF attacks. However I regret that this takes much of the coolness and simplicity out of the concept of session cookies because they get kind of useless for POST requests. Moreover the expiration of the token or session id would render old browser windows useless.

Other ways to avoid the problem are

• Using Java script to embed the session cookie into a hidden field just before submitting
• Using the referer

However not every browser has Java script or referers turned on.

Update: If you too think that browsers should do something about the issue, please consider taking part in the discussion on Bugzilla, which you will find referenced in tinita's original posting.

[tinita]

However I regret that this takes much of the coolness and simplicity out of the concept of session cookies because they get kind of useless for POST requests.

well, i think you're right, but IMHO a session cookie is most useful in GET requests, like viewing a forum thread or something else, so that you can bookmark it easily.
if i had opened a website with a form in it, let the browser window open and try to send the form the next day i would consider it ok if i then get a message that the token is expired.

[betterworld]

if i had opened a website with a form in it, let the browser window open and try to send the form the next day i would consider it ok if i then get a message that the token is expired.

If I don't lose my lengthy texts in the form, that would be all right.

But consider you have 10 tabs open, and on the next morning, you re-login in one tab, and then go through the other 9 tabs one after another to click reload. This isn't exactly fun.

Maybe the best (yet complex) solution is this: One could try to fix the expired tokens via Java script (you can read cookies with Java script). If the server still gets expired tokens (which means that Java script was not available), it could check the referer (and that the method was POST, so that no <img> attacks are possible). If there is no referer, the server can still return an error.

This would make using the site more comfortable for those users who have either Java script or referers turned on, while the site is still usable for other users.

[tinita]

it all depends on how secure you want the application. if you're doing online-banking i think even you are glad that usually you have a timeout of 10 minutes and you can't let windows open and expect them to work an hour later =)