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

Josh Amishav-Zlatin jamuse at owasp.org
Thu Aug 28 09:54:28 UTC 2014


On Thu, Aug 28, 2014 at 10:53 AM, Fabio Cerullo <fcerullo at owasp.org> wrote:

> Guys
>
> My understanding is the following...
>
> Say I have an app with pages A, B, C.
>
> If I have a per session token app, then a mitm attack will allow me to go
> to pages A,B,C because the token would be valid for all of them (until the
> session ends).
>
> However, if I have a per page token app, a mitm attack will allow me as an
> attacker to access the current page browsed by the victim (eg pag A) but in
> theory shouldnt allow me to browse pages B, C.
>
> Additionally, you shouldnt allow concurrent sessions from the same user so
> even if you as an mitm attacker are able to get the victim's session, it
> will not be accepted by the app.
>
> Does it make sense? Great to have this conversation... Please keep
> it flowing.
>
>
Hi Fabio,

Good point for unlinked pages. Of course If page B is the next sequential
page in a given function, presumebly the per page token in page A's
response body linking to page B is accessible to a MiTM attacker. Having
said that, I still like to implement per page tokens as an anti-automation
defense.

- Josh


> Fabio
>
>
> On Wednesday, August 27, 2014, Jerry Hoff <jerry at owasp.org> wrote:
>
>> 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
>>
>>
> _______________________________________________
> 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/20140828/aabe226f/attachment-0001.html>


More information about the OWASP-Leaders mailing list