[Webappsec] blocking CSRF attacks
Jim Manico
jim at manico.net
Tue Dec 18 04:10:55 EST 2007
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
> <mailto: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>
> > <mailto: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>
> <mailto: 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 <mailto: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 <mailto:jim at codemagi.com>
> 808.652.3805 (c)
> 484.259.3805 (f)
>
> _______________________________________________
> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/webappsec/attachments/20071217/6c576403/attachment.html
More information about the Webappsec
mailing list