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

Fabio Cerullo fcerullo at owasp.org
Thu Aug 28 07:53:04 UTC 2014


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.

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 <javascript:_e(%7B%7D,'cvml','jerry at owasp.com');>
> @jerryhoff
>
> On Aug 27, 2014, at 21:19, Jim Manico <jim.manico at owasp.org
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','OWASP-Leaders at lists.owasp.org');>
>> >>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>> >>
>> >>
>> >> --
>> >> Pawel Krawczyk
>> >> pawel.krawczyk at hush.com
>> <javascript:_e(%7B%7D,'cvml','pawel.krawczyk at hush.com');> +44 7879 180015
>> >> CISSP, OWASP
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> OWASP-Leaders mailing list
>> >> OWASP-Leaders at lists.owasp.org
>> <javascript:_e(%7B%7D,'cvml','OWASP-Leaders at lists.owasp.org');>
>> >> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>> > _______________________________________________
>> > OWASP-Leaders mailing list
>> > OWASP-Leaders at lists.owasp.org
>> <javascript:_e(%7B%7D,'cvml','OWASP-Leaders at lists.owasp.org');>
>> > https://lists.owasp.org/mailman/listinfo/owasp-leaders
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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/1526bee8/attachment.html>


More information about the OWASP-Leaders mailing list