Hi,

Igor Vaynberg wrote:
On Tue, Mar 4, 2008 at 4:42 AM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
 The form with the token looks good, the question I have is, why is
 something like it not the default (since almost everybody's site will be
 vulnerable without it)?

because we are a generic framework and i believe the thinking so far
has been that this kind of security is not a requirement but an
exception. clearly if you are building a banking app then security is
the default and unsecure is the exception. eg we can enable csrf
protection out of the box, but then you are completely screwed if you
want to have your website indexed - crawlers dont like different urls
pointing to same content and they dont support sessions.

I'm not saying to by default enable the crypted url strategy. While that may be the "safest" option, I agree that probably nobody wants that (I certainly don't, I'm a big fan of nice urls).

But the form with the token is very non-intrusive and it stops the majority of the CSRF attacks (since the majority occur in form posts). Obviously there may be exceptions, where merely doing a GET on a page with page parameters does an action, and these would not be protected by the form, but would require the token added to the URL or encrypted urls. But this would really be the exception.

So as far as I see, enabling CSRF protection out of the box on forms does not screw up crawlers (crawlers don't post forms), does not mess up the urls (the token is a hidden field), is transparent, simple, and non-intrusive.

if our users tell us they want the security to be the default we would
make the switch...

I wonder how many users know about this attack. I didn't, and I think it would be nice if Wicket protected me even though I didn't! :-)

-igor

Regards,
Sebastiaan

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to