Re: [cmis-browser] CSRF proposal

[Florian Müller <florian.mueller@alfresco.com>]

Hi Scott,

My assumption is that in most scenarios the repository and the 
application reside on different servers and in different domains. So we 
have to bypass the browser policies somehow and we do that with JSONP 
and the cmistransaction value. Therefore, the standard defense 
mechanisms don't work here.

Bypassing the browser policies makes it more vulnerable to attacks. I 
believe the threat is real because it is so easy to write and place a 
malicious script and a DMS can be a valuable target.

We have to find ways to secure it and we cannot rely on the browser and 
it's policies. And you are right, it might also endanger also the 
AtomPub binding.
A solution could be to work with a token that is outside the reach of 
the browser. A token or a variation of the the token (e.g. a hash) that 
has to be deliberately passed from the application to the repository. 
Doing that would secure the browser binding and reduce the risk for the 
AtomPub binding.

We can't leave that to the server administrator. It requires client 
support and therefore has to be in the spec.


Regards,

Florian



On 17/03/2011 19:22, Scott Malabarba wrote:
> Hi Florian,
>
> The idea behind the proposal is that both defenses provide levels of
> security, if implemented properly. They aren't bulletproof. They block
> the straightforward type of CSRF attack where hostile script exploits
> the user's active session to POST destructive data to the target server.
> That's the scope of the current proposal, and the spec must make that
> clear. Other CSRF variants, such as login attacks and the injection of
> JavaScript into text content, are also out of scope.
>
> The custom header is a fairly common CSRF defense. If the server chooses
> to require it, then I think we should facilitate that. Otherwise a
> standard CMIS client will not work.
> The server developers would have to take into the account the fact that
> some clients might not be able to send the header (that was my reasoning
> behind the new services that advertise which CSRF defenses the server
> requires).
>
> The secret token is also a common and well-known defense. It relies on
> the fact that mainstream browsers restrict cross-site GETs in
> JavaScript. JavaScript originating on a hostile web site can make a POST
> cross-site to the target web site, but cannot make a GET (the browser
> either blocks the GET or hides the result). Legitimate browser-based
> clients that make requests to a server other than the one they originate
> from have to work around this. One technique, which we've used
> internally, is to proxy all requests through the server that hosts the
> client app.
>
> There are some exceptions. JSONP and JS hijacking allow scripts
> originating on the hostile site to inject JSON responses from the target
> site into themselves. I don't know what, if anything, we can do at the
> CMIS spec level to block these attacks. And, clearly, if the browser
> does not restrict cross-site GETs then all bets are off.
>
> There are other well-known defenses, such as verifying the Domain or
> Referer (problematic) header. These can be implemented purely
> server-side, either in the CMIS server itself or a web proxy. There's no
> need to account for them in the spec.
>
> So I believe the proposal does work, more-or-less as is. We must clearly
> document its intention and limitations in the spec.
>
> That said, you raise some valid concerns.
>
> We talked about whether or not the CSRF risk extends to the other CMIS
> bindings and whether or not we should raise the topic with the main TC.
> I thought it through a bit more while writing this. The answer is yes.
> Here's my thinking:
> - By introducing a browser binding we encourage people to write
> browser-based clients
> - CSRF attacks require that the victim sign into the target website and
> then visit a hostile website
> - Therefore, we're elevating the risk that people will sign into a CMIS
> server in their browser and then visit a hostile website.
>
> The thing is, it doesn't really matter what server the user signs into
> as long as that server has single-sign on enabled with the CMIS server.
> And it doesn't matter what binding the client application uses. Hostile
> JavaScript can use any binding. In other words, the following scenario
> applies:
> - User signs into some business application that has SSO with CMIS
> enabled. He now has an active CMIS session.
> - User visits hostile web site (oops!) that loads an attack script into
> the browser
> - Attack script makes PUT and POST requests to the CMIS server using the
> REST binding.
>
> We should bring this to the TC. I don't think it has to happen in the
> browser binding timeframe.
> Questions: What's the real risk here? Is there anything we can add to
> the spec to help? Or should it be left to the server administrator?
>
> BTW, one of the CSRF resources I found most helpful was this paper: [1].
>
> Regards,
> Scott
>
> [1] Robust defenses for cross-site request forgery. A. Barth, C.
> Jackson, J. Mitchell, CCS 2008.
> http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf.
>
>
>
> From: Florian Müller <florian.mueller@alfresco.com>
> To: cmis-browser@lists.oasis-open.org
> Date: 03/17/2011 07:02 AM
> Subject: [cmis-browser] CSRF proposal
> ------------------------------------------------------------------------
>
>
>
> Hi,
>
> Maybe I misunderstand the CSRF proposal but I don't think it would work
> for our use case.
>
> A custom HTTP header cannot be set in a simple HTML form and
> XMLHttpRequest is much more difficult to use. It also doesn't provide a
> reliable protection.
> Issuing a new secret token for each POST doesn't protect at all. The
> repository cannot distinguish who requests the token - the application
> or a malicious site.
> The browser sends in all cases the authentication data and the cookies
> that might hold the session identifier to the repository.
> I also think we have to find a solution for GET.
>
>
> Here is a not thought-out and maybe too complex idea:
>
> We add an authenticate() operation. It accepts a JSON object that
> contains the credentials via POST and returns a JSON object that
> contains an access token and maybe an expiration timestamp (and maybe
> all repository infos).
> A repository should associate that login with a session and remember the
> access token.
>
> All GET URLs have to be signed with this token. That is, the access
> token becomes the key and URL becomes the message of a HMAC function.
> The hash is added to tho URL.
>
> Example:
> Token: 123456
> original URL:
> http://cmis.example.com/cmis/repository/123/myFolder?cmisselector=getChildren&maxItems=100
> <http://cmis.example.com/cmis/repository/123/myFolder?cmisselector=getChildren&maxItems=100>
> final URL:
> http://cmis.example.com/cmis/repository/123/myFolder?cmisselector=getChildren&maxItems=100&hash=97930edb97971c928eb02d6bc557e84eb70ce608
> <http://cmis.example.com/cmis/repository/123/myFolder?cmisselector=getChildren&maxItems=100&hash=97930edb97971c928eb02d6bc557e84eb70ce608>
>
> The repository can recalculate the hash to verify that it was the
> application that generated the link for that user. It cannot prevent
> replay attacks but makes any other attack really difficult.
>
> For POSTs we already have the cmistransaction value that the client
> generates. It becomes the message of the HMAC function and the hash is
> added to the form.
>
> Example:
> Access token: 123456
> Transaction token: abcdef
>
> <form ...>
> ...
> <input name="cmistransaction" type="hidden" value="abcdef" />
> <input name="hash" type="hidden"
> value="263d983cab1a7ed9bc35fbf41e4e75aed7188b2c" />
> </form>
>
>
> If a repository doesn't require authentication, the access token can be
> empty and hash values don't have to be added.
>
>
> Another way to solve our problem could be CORS (Cross-Origin Resource
> Sharing) [1].
> Unfortunately, it's not supported by all browsers, yet. Nevertheless, I
> think we could mention it in the spec.
>
>
> Comments?
>
>
> Regards,
>
> Florian
>
>
> [1] http://www.w3.org/TR/cors/
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>