Re: [cmis-browser] CSRF proposal

[Scott Malabarba <scott.malabarba@us.ibm.com>]

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>
> 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
>
>


---------------------------------------------------------------------
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