[Webappsec] blocking CSRF attacks and cross domain/document messaging
Jim Manico
jim at manico.net
Wed Dec 19 16:46:15 EST 2007
Not so fast, Ray. Your original assumptions were more correct than not
with todays current browsers. Let me walk thorough my claims below and
point out where I was wrong.
*1) In the past we saw hacks using IFRAME tricks to get around JS SOP.
(*|involved document.domain| modification)
That might be true, but all browsers have locked this vector down
*tightly* and all POC code breaks against the latest and greatest. The
historical hack was - you load a form via an iframe, then use JS to grab
the token from the DOM to initiate cross-domain request. This is not
longer possible on any of the current "big 3" browsers.
*2) And today, we have Opera 8/9 which allow cross-document messaging
*/*on purpose:
*/That might be true, but that requires opt-in policy. Quoting Tom
Stripling, "this spec would allow JavaScript running in one domain to
call certain functions in JavaScript running on another domain. So,
this is cross-domain access, but it still requires both domains to
cooperate by placing JavaScript on the page that can send/receive the
request."
*3) I also made some claims about FLASH being able to initiate
cross-domain requests. *
This is true, but Flash will only allow a cross-domain post/get request
if the target server has a crossdomain.xml deployed in a public
directory that states which target sites are allowed to initiate the
cross domain request.
I tried doing a google advanced search (do not try this at home) where
the "with all of these words" was domain="*" and "with the exact phrase"
was "inurl:crossdomain xml" and google promptly locked me out of their
site for a little while. Hah! But still if you google on
inurl:crossdomain.xml you see plenty of sites with fairly wide open
policy. Not recommended. :)
*4) I also made claims about earier build of FF 3 where cross-domain
request could be done without policy - but our POC code no longer works
with the last few builds, they havfe moved to the whatwg standard as well.
*Sure, but only for the early alpha builds. Our POC code no longer works
for the latest build.
*
* Even w3c's cross-domain working group required opt-in policy
http://www.w3.org/TR/access-control/ . So I was clearly wrong on this
thread, you are right on Ray and I'm going to stop spamming the OWASP
community. Thanks to Tom Stripling and others for taking the time to
debate/educate me on these points in a very respectful manner.
Aloha,
Jim
***
> Looks like my base assumptions were wrong Jim. Have to agree that SOP
> bypasses are just as readily available too. Good points there :)
>
> Ray
>
> On Dec 19, 2007 2:30 AM, Jim Manico < jim at manico.net
> <mailto:jim at manico.net>> wrote:
>
> Thank you Jeff, this is very helpful.
>
> I'd also like to step back from my point that "JS SOP is fairly
> bullet-proof". After manic research this morning, I no longer
> think this to be true.
>
> In the past we saw hacks using IFRAME tricks to get around JS SOP.
>
> http://fettig.net/weblog/2005/11/30/xmlhttprequest-subdomain-update
>
> And today, we have Opera 8/9 which allow cross-document messaging
> /*on purpose:*/
>
> http://virtuelvis.com/archives/2005/12/cross-document-messaging
> http://dev.opera.com/articles/view/web-technologies-for-opera-web-applicati/#crossdoc
>
> Flash allows you to do cross-domain messaging already.
>
> In the near future, FireFox 3.0 will support cross document
> messaging.
>
> And this all stemmed from the HTML 5 recommendation from What-WG
>
> http://www.whatwg.org/specs/web-apps/current-work/#crossDocumentMessages
>
> So I go back to my original conjecture that CSRF token defense
> will not protect you from a 3rd party malicious site ripping the
> token from a form (taking advantage of the fact that you are
> already logged in to the site that the attacker wishes to
> exploit). This attack can only (easily) be mounted against Opera
> in pure JS- but "/times they are a changin'/".
>
> And although mounting this kind of CSRF is not easily done in a
> cross-browser way today, the future of cross document messaging
> necessitates that we get ready for the inevitable future.
>
> - Jim
>
>
>
> Jeff Williams wrote:
>>
>> 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>
>> [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 <mailto: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
>> <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
>> >
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/webappsec/attachments/20071219/eae46b5d/attachment.html
More information about the Webappsec
mailing list