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

Jerry Hoff jerry at owasp.org
Wed Aug 27 18:30:43 UTC 2014


Exactly - a mitm attack would compromise your session cookie anyway. So saying changing CSRF tokens defends against mitm doesn't make much sense to me.

If a single session cookie is good enough to protect the session, why wouldn't a single anti-CSRF token be good enough to defend against forgery for the entire session? 

--
Jerry Hoff
jerry at owasp.com
@jerryhoff

> On Aug 27, 2014, at 21:19, Jim Manico <jim.manico at owasp.org> wrote:
> 
> 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> wrote:
>>> Thanks for the replies team.
>>> 
>>> Sent from my iPhone
>>> 
>>> > On 20 Aug 2014, at 16:23, Jim Manico <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> 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> 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
>>> >>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>> >>
>>> >>
>>> >> --
>>> >> Pawel Krawczyk
>>> >> pawel.krawczyk at hush.com +44 7879 180015
>>> >> CISSP, OWASP
>>> >>
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> OWASP-Leaders mailing list
>>> >> OWASP-Leaders at lists.owasp.org
>>> >> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>> > _______________________________________________
>>> > OWASP-Leaders mailing list
>>> > OWASP-Leaders at lists.owasp.org
>>> > https://lists.owasp.org/mailman/listinfo/owasp-leaders
>>> _______________________________________________
>>> OWASP-Leaders mailing list
>>> 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
>> Email: munir.njiru at owasp.org
>> Facebook: https://www.facebook.com/OWASP.Kenya
>> Mailing List: https://lists.owasp.org/mailman/listinfo/owasp-Kenya
> 
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20140827/f6484c64/attachment.html>


More information about the OWASP-Leaders mailing list