cmis-browser message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [cmis-browser] CSRF proposal
- From: Scott Malabarba <scott.malabarba@us.ibm.com>
- To: Florian Müller <florian.mueller@alfresco.com>
- Date: Thu, 17 Mar 2011 12:22:50 -0700
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
- References:
- CSRF proposal
- From: Florian Müller <florian.mueller@alfresco.com>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]