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

Josh Amishav-Zlatin jamuse at owasp.org
Thu Aug 28 10:49:49 UTC 2014


On Thu, Aug 28, 2014 at 12:59 PM, psiinon <psiinon at gmail.com> wrote:

> Then you get the likes of me making automation and token regeneration easy
> with Zest.
>
> Sorry ;)
>
>
Sounds cool! Can Zest access JavaScript injected form OTP tokens?

- Josh


>
> 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/f45b4717/attachment-0001.html>


More information about the OWASP-Leaders mailing list