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

Munir Njiru munir.njiru at owasp.org
Mon Aug 25 07:01:09 UTC 2014


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp-leaders/attachments/20140825/5ac02d41/attachment-0001.html>


More information about the OWASP-Leaders mailing list