Re: [cmis-browser] CSRF proposal

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

I'm not sure I understand how changing the format of the response makes 
it more secure.
We need JSONP to bypass the same origin policy. Therefore, the result 
has to be something interpretable by a JavaScript engine.
If we don't allow JSONP, the application must be in the same domain as 
the repository and that's not a typical setup.


By "outside the reach of the browser" I mean we shouldn't use cookies or 
basic authentication. We should avoid everything a browser would send 
again in further requests to the repository without asking.
A token in a JavaScript variable would work because its meaning is only 
known to the application. The application could actually store that 
token in a cookie because it can restrict the visibility of this cookie 
to the application. With an application cookie in place, a user could 
leave and return to the application until the token or the cookie expires.

My description of the authenticate() function was deliberately vague. We 
should standardize username/password authentication but should also 
allow other methods. The authenticate() function should accept a map and 
the application can provide whatever identifies the user. This 
identification should be something a repository can check or trust. An 
empty map could mean that authentication should be done somehow by the 
container.
We probably to have to define a fallback login page, too. This page 
should be served by the repository to allow all kinds of authentication 
methods supported by the repository.

Authentication in general is something we should discuss in the TC 
again. The other bindings face similar challenges.

We should discuss this whole topic again in the next subcommittee call.
@Greg: Could you please put it on the agenda?!


- Florian



On 18/03/2011 20:08, Scott Malabarba wrote:
> There's an easy way to secure the secret token service against
> JSONP-based attacks: don't return JSON.
> A plain text response is easy for clients to read and, as long as we
> don't allow the client to request padding for it, can't be injected into
> JavaScript.
>
> That lets us secure the form POST endpoint. In the browser binding
> context, it's important to focus on that because a) basic form POST CSRF
> attacks are trivial to code up and can destroy or corrupt data, b) it's
> a new potential vulnerability that the browser binding introduces and c)
> it's an easier problem to solve. It's possible that a comprehensive
> cross-binding solution could supplant the current proposal. But that
> will take some time to work that out, and I don't think the browser
> binding spec is complete without some provision for CSRF.
>
>
> It is clear that there is a risk across all bindings and endpoints. How
> do you want to proceed? Discuss in the next subcommittee meeting?
> This seems to me like a good topic for a TC working group.
>
> A couple of questions about what you've proposed:
>
> Could you elaborate on this? Specifically, what you mean by "outside the
> reach of the browser".
>
>  > 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
>
>
> The authenticate() function that returns a token is part of a class of
> solutions that pushes authentication into the CMIS API.
> How do people feel about this? It has implications for both client and
> server implementations. For instance, a Dojo widget client running
> within a mashups container
> might not have any way to get user credentials. It would have to add a
> login page and, if the Javascript were unloaded for any reason (say,
> user clicks to a help page, then back) it would have to re-authenticate
> because it lost the token. A J2EE-based server might not handle
> authentication either, leaving it to the container. We'd also have login
> CSRF to worry about.
>
> Regards,
> Scott
>
>
>
>
>
>
> From: Florian Müller <florian.mueller@alfresco.com>
> To: cmis-browser@lists.oasis-open.org, Scott Malabarba/Costa Mesa/IBM@IBMUS
> Date: 03/18/2011 03:21 AM
> Subject: Re: [cmis-browser] CSRF proposal
> ------------------------------------------------------------------------
>
>
>
> 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>
>  >
> <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>
>  >
> <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
>  >
>  >
>
>
> ---------------------------------------------------------------------
> 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
>
>