OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cmis-browser message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cmis-browser] CSRF proposal


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
 final URL:    
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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]