[Webappsec] blocking CSRF attacks

Tue Dec 18 04:35:57 EST 2007

It would be interesting to see the results from this debate.  If controlled
read access to external resources can be done securely, it would be a big
step forward.  A big "IF"  ;)

Ray

On Dec 18, 2007 5:10 PM, Jim Manico <jim at manico.net> wrote:

>  Indeed Ray, I'm with you now.
>
> I'm thinking ahead - W3C is debating allowing AJAX/JS requests that
> violate SOP *by design* for more in-depth mash-up functionality. If they do
> go that far, then I think it would be a serious mistake.
>
> I still feel that the current token defense best practice is weak, at
> best. Does anyone know of a more rigorous defense (practice or theory) that
> could even stop a banking trojan?
>
> - Jim
>
> Ray Foo wrote:
>
> My comments below:
>
> On Dec 18, 2007 4:56 PM, Jim Manico <jim at manico.net> wrote:
>
> > Sorry, I didn't address Ray's comments correctly.
>
>
> >
> > Even if you are using standard form key token defense, are still logged
> > onto good site A and navigate to evil site B, the evil site can store JS
> > that can simply request a copy of the form that the attacker wishes to
> > exploit, then rip the token value (and name, not to hard to figure out)
> > via JS, and use that token to mount a CSRF attack - again from a
> > secondary site even when good site A uses all defensive coding best
> > practices. It's this kind of vector that requires a complex navigational
> > form token defense strategy as I described in my earlier post.
>
>
> This would require the bypassing of the same origin policy on the browser
> (to rip off the token name and value from the victim site page).  In this
> case, even navigational form tokens can be compromised also, isn't it?
>
>
> >
> > And this doesn't even begin to stop banking Trojans that just sit on
> > your machine waiting for you to log in.....
> >
>
> Very true...if the victim user's machine's compromised.  We can almost
> count it as game over already =|
>
>
> > Current CSRF best practices are weak at best from savvy attacks, I
> > think.
>
>
> > - Ji
> >
> >
> > Ray Foo wrote:
> > > 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
> >  > <mailto: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 <mailto: Webappsec at lists.owasp.org>
> > >     https://lists.owasp.org/mailman/listinfo/webappsec
> > >
> > >
> >  >
> > ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Webappsec mailing list
> > > Webappsec at lists.owasp.org
> > > https://lists.owasp.org/mailman/listinfo/webappsec
> > >
> >  >
> > ------------------------------------------------------------------------
> > >
> > > No virus found in this incoming message.
> > > Checked by AVG Free Edition.
> > > Version: 7.5.503 / Virus Database: 269.17.4/1188 - Release Date:
> > 12/17/2007 2:13 PM
> > >
> >
> > --
> > Best Regards,
> > Jim Manico
> > VP Software Engineering, Codemagi Inc.
> > Application Security Instructor, Aspect Security
> > jim at codemagi.com
> > 808.652.3805 (c)
> > 484.259.3805 (f)
> >
> >  _______________________________________________
> > Webappsec mailing list
> > Webappsec at lists.owasp.org
> > https://lists.owasp.org/mailman/listinfo/webappsec
> >
>
> ------------------------------
>
> _______________________________________________
> Webappsec mailing listWebappsec at lists.owasp.orghttps://lists.owasp.org/mailman/listinfo/webappsec
>
> ------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.503 / Virus Database: 269.17.4/1188 - Release Date: 12/17/2007 2:13 PM
>
>
>
> --
> Best Regards,
> Jim Manico
> VP Software Engineering, Codemagi Inc.
> Application Security Instructor, Aspect Securityjim at codemagi.com808.652.3805 (c)484.259.3805 (f)
>
>
> _______________________________________________
> 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/978f79ef/attachment-0001.html 