Re: [cmis-browser] CSRF discussion

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

David Choy, Jay Brown and I met this morning.
David is adding the topic to the agenda
for the F2F meeting.  We agreed that another call next week would
be helpful.

Some form of the double submit cookie
technique might do.  Here's how it typically works:

- When the user visits a site, the server
creates a secret token and sets it in a cookie (say, AntiCsrf).
- On any form POST, the client application
must submit a form input AntiCsrf with the secret token read from the cookie.
- The server validates the POST request
by comparing the AntiCsrf form input and the cookie.  If either is
absent or they do not match, it rejects the request.

For additional security the server can
build some intelligence into token -- say, cryptographically signing it
to verify origin -- and use the standard cookie expiry field.

It's difficult for malicious script
from another domain to read the cookie value.  Might not be impossible.
 This isn't clear to me yet.  The cookie cannot 
be HttpOnly since JavaScript clients
will need to read it.

Even if the attacker knows the secret
token, it cannot set a cookie across domains.  For strongest protection,
then, I think that the server should validate the 
domain on the cookie in addition to
the token value.  This would require the use of a whitelist of allowed
domains (also necessary for CORS).

The technique could also be used to
secure GETs.  The token would have to be passed as a URL parameter.
 Two issues here:  
- The token could more easily leak to
an attacker.  Domain validation on the cookie becomes more important.
- Either the server sets the cookie
on authentication -- which might happen outside the CMIS code -- or the
first GET call is unprotected.  We might need
  to specify a special GET call
that does not return any useful information and require that clients call
it first.  And again, domain validation is important.
  Otherwise the attacker could
just make the same GET call.

Haven't read anything about validating
the cookie's domain in the literature on this technique.  Might be
that people tend to assume that the attacker can't
get the token.  Or maybe I have
something wrong.

Let's pick this one apart.

Regards,
Scott





From:      
 Scott Malabarba/Costa
Mesa/IBM@IBMUS
To:      
 Florian Müller <florian.mueller@alfresco.com>
Cc:      
 cmis-browser@lists.oasis-open.org
Date:      
 05/12/2011 05:45 PM
Subject:    
   Re: [cmis-browser]
CSRF discussion

---

Good idea.  I scheduled a call
for tomorrow, 9AM PST -- hope that works for you.  If not, any day
next week. 


I've mostly come around to your way of thinking on this.  There isn't
any safe way for the server to pass a secret token
to the client, outside the context of some kind of authenticate() call
like you proposed earlier. 

If I understand CORS correctly, server developers or administrators could
use it to secure their servers as an alternative 
to requiring the separate authenticate() call, at the cost of reduced browser
compatibility.  This wouldn't have to be part
of the API, though it could be mentioned in the spec as something like
"The server SHOULD enable CORS filtering..."

We might be able to do something with cookies.  And I've got a couple
of other less promising ideas. 

Regards, 
Scott 





From:        Florian
Müller <florian.mueller@alfresco.com> 
To:        cmis-browser@lists.oasis-open.org
Date:        05/12/2011
08:15 AM 
Subject:        [cmis-browser]
CSRF discussion

---

Hi all,

Can we restart the CSRF discussion before the face-to-face meeting?

I would like to conclude this topic as soon as possible - maybe at the
meeting or soon after.
I haven't continued the OpenCMIS implemenation because of this...


Cheers,

Florian

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