[Webappsec] blocking CSRF attacks

[Ray Foo]

Correct me if I'm wrong: I think if the token can be retrieved from the form
via JavaScript, it would be possible to retrieve/post the page flow and
their tokens using JS also.

That's what the Same Origin Policy (SOP) is meant to protect against: the
reading/accessing of data of webpages from site B using code downloaded from
site A.

Using random tokens on the submitting form itself should be sufficient in
this case, assuming that the SOP of the user agent is not compromised in any
way.

Ray

On Dec 18, 2007 4:22 PM, Stephen de Vries <stephen at twisteddelight.org>
wrote:

>
> On Dec 14, 2007, at 7:57 PM, Paul Johnston wrote:
>
> > Hi,
> >
> >> any one on the list aware of any IDS/IPS capable of blocking CSRF
> >> attacks? If not, what will be the best policy to block CSRF.
> >>
> > The best fix is to code you application to include a random token on
> > all forms that cause an action, and validate this when the form is
> > submitted.
>
> If the token is only on the form, then this is still vulnerable to
> CSRF as the attacker would just need to write a bit of JavaScript that
> gets the page the form is on first, then reads the token and then
> posts the form using the valid token.  So for the random token to
> work, it would have to be applied to the whole click through route a
> user can take to get to a form from login... and each link must
> validate the previous token.
>
> Stephen
>
> _______________________________________________
> Webappsec mailing list
> Webappsec at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/webappsec
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/webappsec/attachments/20071218/b7a5a729/attachment.html