[Owasp-leaders] CSRF unique per session or per action?

Jim Manico jim.manico at owasp.org
Wed Aug 27 18:19:36 UTC 2014


How does a different CSRF token per-request or per form reduce risk (as 
opposed to one CSRF token per session)? If you are trying to protect 
your app from CSRF in the face of XSS, even a per-request token does 
little to stop a "stored CSRF" attack or a CSRF attack stored on your 
site via an XSS point of entry.

I think a combination of new (unique and random) CSRF tokens per 
login/session creation, a limited session (idle and absolute timeout), 
complete XSS defense and re-authentication at critical junctures is a 
more appropriate CSRF defense strategy.

A lot of smart folks have told me that per-form tokens are better, but I 
have yet to hear a technical argument as to why. Anyone?

Aloha,
Jim



On 8/25/14, 12:01 AM, Munir Njiru wrote:
> I agree with the fact that they should change per session and per form 
> . Predictability would make it easier for any person trying to attack 
> it. Opens up roads for replays at a given point in time. Static 
> variables increase chances of attack . Take it for instance someone 
> has a csrf token assigned per session and uses it through out all an 
> attacker would technically need at that point is ensure they get a 
> valid one and use it to attempt csrf attacks through out the whole 
> application as the line of defence would not change creating valid 
> posts to the application.
>
>
> On Wed, Aug 20, 2014 at 6:36 PM, Christian Papathanasiou 
> <christian.papathanasiou at owasp.org 
> <mailto:christian.papathanasiou at owasp.org>> wrote:
>
>     Thanks for the replies team.
>
>     Sent from my iPhone
>
>     > On 20 Aug 2014, at 16:23, Jim Manico <jim.manico at owasp.org
>     <mailto:jim.manico at owasp.org>> wrote:
>     >
>     > Be careful with the cookie-to-header (ie: double-submit cookie) CSRF
>     > defense. If you open up origin policy for mash-ups and the like, the
>     > defense is no longer effective.
>     >
>     > --
>     > Jim Manico
>     > @Manicode
>     > (808) 652-3805
>     >
>     >> On Aug 20, 2014, at 10:16 AM, Pawel Krawczyk
>     <pawel.krawczyk at hush.com <mailto:pawel.krawczyk at hush.com>> wrote:
>     >>
>     >> Christian,
>     >>
>     >> It depends on why and how it’s going to be implemented. Typical
>     “per form” CSRF token would be a pain in AJAX based apps because
>     you actually need to generate the pages on the server and embed
>     the token. This is why cookie-to-header tokens are gaining
>     popularity in AJAX apps - technically you’ve got a single token
>     for the whole application, but the level of protection against
>     CSRF attacks remains pretty much the same:
>     >>
>     >> https://en.wikipedia.org/wiki/CSRF#Cookie-to-Header_Token
>     >>
>     >>
>     >>> On 20 Aug 2014, at 16:00, Christian Papathanasiou
>     <christian.papathanasiou at owasp.org
>     <mailto:christian.papathanasiou at owasp.org>> wrote:
>     >>>
>     >>> In an internal debate with a colleague who having read the
>     OWASP CSRF cheat sheet wants to implement a static CSRF token
>     across whole application.
>     >>>
>     >>> I'm trying to convince them otherwise as having a static CSRF 
>     token rather than one that is generated on the fly per form
>     submission would technically be akin to having a static otp.
>     >>>
>     >>> Keen to get your thoughts and if you tend to lean toward my
>     view point would be keen to also see that the cheat sheet is
>     updated  :-)
>     >>>
>     >>> Kind regards,
>     >>> Christian
>     >>> _______________________________________________
>     >>> OWASP-Leaders mailing list
>     >>> OWASP-Leaders at lists.owasp.org
>     <mailto:OWASP-Leaders at lists.owasp.org>
>     >>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>     >>
>     >>
>     >> --
>     >> Pawel Krawczyk
>     >> pawel.krawczyk at hush.com <mailto:pawel.krawczyk at hush.com> +44
>     7879 180015
>     >> CISSP, OWASP
>     >>
>     >>
>     >>
>     >> _______________________________________________
>     >> OWASP-Leaders mailing list
>     >> OWASP-Leaders at lists.owasp.org
>     <mailto:OWASP-Leaders at lists.owasp.org>
>     >> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>     > _______________________________________________
>     > OWASP-Leaders mailing list
>     > OWASP-Leaders at lists.owasp.org <mailto:OWASP-Leaders at lists.owasp.org>
>     > https://lists.owasp.org/mailman/listinfo/owasp-leaders
>     _______________________________________________
>     OWASP-Leaders mailing list
>     OWASP-Leaders at lists.owasp.org <mailto:OWASP-Leaders at lists.owasp.org>
>     https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>
>
>
> -- 
> Munir Njenga,
> OWASP Chapter Leader (Kenya) || Information Security Consultant || 
> Developer
> Mob   (KE) +254 (0) 734960670
>
> =============================
> Chapter Page: www.owasp.org/index.php/Kenya 
> <https://www.owasp.org/index.php/Kenya>
> Email: munir.njiru at owasp.org <mailto:munir.njiru at owasp.org>
> Facebook: https://www.facebook.com/OWASP.Kenya
> Mailing List: https://lists.owasp.org/mailman/listinfo/owasp-Kenya
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20140827/c9553f88/attachment.html>


More information about the OWASP-Leaders mailing list