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

psiinon psiinon at gmail.com
Thu Aug 28 09:59:45 UTC 2014


Then you get the likes of me making automation and token regeneration easy
with Zest.

Sorry ;)


On Thu, Aug 28, 2014 at 10:54 AM, Josh Amishav-Zlatin <jamuse at owasp.org>
wrote:

> 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
>>
>>
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
>


-- 
OWASP ZAP <https://www.owasp.org/index.php/ZAP> Project leader
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20140828/4aa53a79/attachment.html>


More information about the OWASP-Leaders mailing list