[Webappsec] CSRF Nonce

[jeff williams]

Keith,

If you're serious about implementing this (and not using CSRFGuard) you may
be interested in the OWASP ESAPI
<http://www.owasp.org/index.php/ESAPI>project.  The Java edition is
ready, the .NET and PHP versions are in
progress.  There are several methods in the
HTTPUtilities<http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/org/owasp/esapi/HTTPUtilities.java>
code
that will help you.  One of the bigger challenges is to know when NOT to
enforce the CSRF protection.  You can't enforce CSRF on any page that you
expect people to enter from or bookmark.  Otherwise they'll send a request
without the right token and get kicked out.

I think using a token containing the hashed sessionid is a reasonable
protection strategy for CSRF. I wouldn't recommend using MD5 anymore, it's
generally considered weak (along with SHA-1).  You might find the
Encryptor<http://code.google.com/p/owasp-esapi-java/source/browse/trunk/src/org/owasp/esapi/Encryptor.java>code
useful.  It does salted SHA-512, with a strong number of iterations.

--Jeff

On Mon, May 12, 2008 at 4:04 PM, Knippa, Keith <
Keith.Knippa at austin.utexas.edu> wrote:

>  Thanks to both of you for your comments.
>
>
>
> Jeff, I like the approach that you suggested of storing a completely
> random token in a user's session.  The simplicity of the approach outlined
> in my original request for comment attracts me, however, because it would be
> somewhat straight forward to implement in a legacy system.  So, if you don't
> mind, I have a follow up question to what you said about hashing the session
> token not being a bad idea.  Are you saying it wouldn't be bad practice (not
> the best) to apply a salted md5 hash of the session id in a hidden field
> using the scheme outlined in the original post?   I like that because it
> doesn't require session storage for random tokens.
>
>
>
> And Chris, I'm not sure that I understand what you mean by a custom header
> approach.  If haven't come across that as a way of defending against CSRF
> attacks.  Are you suggesting that the session ID be stored in a custom
> header?
>
>
>
> Thanks again, Keith
>
>
>  ------------------------------
>
> *From:* Chris Weber (Casaba Security) [mailto:chris at casabasecurity.com]
> *Sent:* Monday, May 12, 2008 12:46 PM
> *To:* 'jeff williams'; Knippa, Keith
> *Cc:* webappsec at lists.owasp.org
> *Subject:* RE: [Webappsec] CSRF Nonce
>
>
>
> Unless I'm missing something about this scenario, you don't 'have to' put
> the session Id in the URL for GET requests.  You could always add it as a
> custom HTTP header and avoid the problems you mention.
>
>
>
> Chris
>
>
>
>
>
> *From:* webappsec-bounces at lists.owasp.org [mailto:
> webappsec-bounces at lists.owasp.org] *On Behalf Of *jeff williams
> *Sent:* Monday, May 12, 2008 8:58 AM
> *To:* Knippa, Keith
> *Cc:* webappsec at lists.owasp.org
> *Subject:* Re: [Webappsec] CSRF Nonce
>
>
>
> If you embed the actual session cookie value in the HTML, there's more of
> a chance that an attacker could steal it.  They might find it in a cached
> page.  Or if there's an XSS hole, but http-only is enabled, this would allow
> them to get your session cookie.  Since you probably need CSRF protection on
> GET requests, you'll have to put the session id in the URL too, where it
> could be logged, bookmarked, included in referer, etc...  Stealing the
> session cookie is worse than CSRF, because then the attacker can hijack your
> entire session.  CSRF is a much more difficult attack to pull off in
> practice.
>
>
>
> Hashing the session token isn't a bad idea, but I prefer generating a
> completely random token that is stored in the user's session.  For more on
> this, check out the implementation of CSRFGuard (
> http://www.owasp.org/index.php/CSRFGuard).  If you're interested in
> testing for CSRF, you may find CSRFTester (
> http://www.owasp.org/index.php/CSRFTester) useful.
>
>
>
> --Jeff
>
> On Mon, May 12, 2008 at 11:35 AM, Knippa, Keith <
> Keith.Knippa at austin.utexas.edu> wrote:
>
> Hello,
>
>
>
> I'd appreciate feedback on the idea of using the value of a system
> generated session cookie as a hidden value in a web page to insure that an
> application generated a page so as to defend against CSRF.  I've seen this
> approach suggested in several places.  Some sources suggest the additional
> step of applying a MAC algorithm to session identifier.  I can't understand
> why such an additional step would be necessary.
>
>
>
> Thank you for your time and thoughts.
>
>
>
> Keith
>
>
> _______________________________________________
> Webappsec mailing list
> Webappsec at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/webappsec
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/webappsec/attachments/20080512/7564cc11/attachment.html