search

solid / specification

Solid Technical Reports
https://solidproject.org/TR/
MIT License
490 stars 46 forks source link

Cookie related security considerations for solid storage (RS) implementations #218

Open elf-pavlik opened 3 years ago

elf-pavlik commented 3 years ago

Yesterday during authentication call we noticed need to capture security considerations related to use of cookies in solid storage implementations. I'll capture initial thoughts and we can fill in the rest in following comments.

  1. Cookie based access should be restricted to read operations, write (including append) should employ app using access tokens.
  2. Cookie should be set with SameSite=Lax which browsers make new default. This would prevent third party applications to use cookie instead of access token.

Above considerations relate to avoiding clients circumventing client specific restrictions by using cookie (if available) instead of access token.

@acoburn has some implementation experience including exploration of setting client identifier in a cookie etc.

elf-pavlik commented 3 years ago

We discuss cases where user needs to access protected resource by navigating their web browser to it (eg. following a link from message etc.) https://github.com/solid/authentication-panel/issues/31

In that case the solid storage would as as OIDC RP (the OAuth client) so access token wouldn't be used, only Id Token which would allow user to 'log in' to the specific storage. To my understanding solid storage in that scenario doesn't act as OAuth RS, which might make things bit confusing.

EDIT: I looked in the past how to avoid using cookies by leveraging service workers https://github.com/solid/solid/issues/143 but this doesn't seem to help in cases mentioned above.

acoburn commented 3 years ago

@RubenVerborgh I share your concerns about cookie-based auth on the RS, which is why I have generally resisted any form of cookies at that layer. However, there are some practical considerations that have made me reconsider that position.

While accessing resources in the context of an app, auth headers should absolutely be the mechanism used for all forms of authentication, but there are cases where a user jumps out of the context of an app:

  1. Right click on an image to "open image in new tab". This fails without cookies (unless the app captures these events)
  2. Download / Save As... only works if the client app re-implements what a browser does natively (e.g. Blob API)
  3. Open link in new tab will fail unless the JS app captures all link events and rewrites them

It is also reasonable to argue that none of these are technical issues per se, but rather issues about user and developer expectations: do common users actions in a browser work as expected? does a developer need to reimplement features that a browser supports natively?

All of this also raises the question: is any of this a spec-level issue or is it an implementation decision?

elf-pavlik commented 3 years ago

All of this also raises the question: is any of this a spec-level issue or is it an implementation decision?

Even if we decide to leave most of the decisions up to implementations, we should document known security consideratios so that implementers can make well informed decisions.

acoburn commented 3 years ago

FWIW, I'm also inclined to say "implementation", though some non-normative language guiding implementers would be great, especially as this relates to security.