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


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