[Webappsec] blocking CSRF attacks

Tue Dec 18 12:52:15 EST 2007

The OWASP CSRFTester tool records the timing between steps of a transaction and plays the results back realistically. This came up when doing CSRF testing about a year ago on an application that couldn’t process our requests fast enough.  If you’re interested at all in CSRF I highly recommend playing around with the tool and studying the HTML it produces.

And don’t forget about the OWASP CSRF Guard if you’re interested in protecting against CSRF attacks.

--Jeff

From: webappsec-bounces at lists.owasp.org [mailto:webappsec-bounces at lists.owasp.org] On Behalf Of Jim Manico
Sent: Tuesday, December 18, 2007 11:50 AM
To: webappsec @OWASP
Subject: Re: [Webappsec] blocking CSRF attacks

First of all, JS SOP is fairly bullet-proof. My mistake as I was moving to fast late at night. :)

Just one more point on the subject of defeating banking trojans and CSRF and I'll stop spamming this list.

When a human logs-on to a banking website and then navigates through a few pages in order to make a transaction, there is significant variance of time between clicks.

Yes for almost all multi-step CSRF that we have seen in the wild (like the NetFlix CSRF from a few years back) there is significant temporal determinism that should be easily detectable.

So I still conjecture that when protecting financial assets, it might be prudent to come up with a navigational-session-key scheme that tracks the "path" of a user as well as measures time between clicks to possibly build in advanced CSRF IDS capability on the server side. A scheme of this sort might even be able to stop or detect that a banking trojan is in play.

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)

Jim Manico 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: <mailto:Webappsec at lists.owasp.org>  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 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)

-- 
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/20071218/3f0abf17/attachment.html 