Comments on: CSRF browser protection

By: Iehrepus

Iehrepus — Tue, 20 Nov 2007 14:06:14 +0000

heh,’Active Defense’ for browser?
your idea like me?

CSRF attacks not only a server side problem,bcz
the attacks start from clint

By: Gareth Heyes

Gareth Heyes — Mon, 19 Nov 2007 13:50:13 +0000

Cool stuff Mario! The more protection we can have against CSRF the better as far as I’m concerned.

By: .mario

.mario — Mon, 19 Nov 2007 13:43:42 +0000

Just in case someone wants to know: We have gone live with this tool one week ago and no bad surprises yet

http://code.google.com/p/csrfx/

Greetings,
.mario

By: Gareth Heyes

Gareth Heyes — Mon, 19 Nov 2007 11:40:04 +0000

Yep I understand this is a server side problem but if the requests don’t reach the server from the user’s browser then the attack cannot be accomplished.

The browser is acting as a Firewall for the requests in this instance, it isn’t foolproof but it could prevent most CSRF attacks.

By: Shahar Evron

Shahar Evron — Mon, 19 Nov 2007 11:35:35 +0000

The way I understand it, (C|X)SRF is not a client side issue - it’s a server side issue, hence a real solution is only possible from the server side, and only solvable in the application, and by someone that is well familiar with the desired behavior of the application.

CSRF, and even POST-based CSRF can be triggered from other sites (and even by fooling the trusted user into visiting the attacker’s site) and not necessarily from the attacked site using an XSS vulnerability.

I’ve always found using single-request disposable tokens when any form is submitted to be a good solution for CSRF, and it’s also easy to implement.

In general, I think programmers should be aware of this, just like they should be aware of Session Hijacking attacks - both problems should be solved in the application itself by the programmer and not in the client side.