Skip to content
This repository has been archived by the owner on Apr 13, 2022. It is now read-only.

Solid sends WS messages on private resources without authentication #232

Open
WhyINeedToFillUsername opened this issue Feb 24, 2021 · 3 comments

Comments

@WhyINeedToFillUsername
Copy link

E.g. https://inbox1.inrupt.net/inbox/ is not accessible without authentication (GET returns 401). But anybody can subscribe to it without any authentication/authorization:
var socket = new WebSocket('wss://inbox1.inrupt.net/inbox/', ['solid-0.1']);
This way I get notifications for e.g. new messages in that inbox.
(observed on https://inrupt.net/ - server version Solid 5.6.4)

Is that intentional? I can see this as potentially insecure, if e.g. someone subscribes to some more specific resource to watch if it was updated or not.

I don't see any spec regarding auth at https://github.com/solid/solid-spec/blob/master/api-websockets.md.

@jeff-zucker
Copy link

jeff-zucker commented Feb 25, 2021

AFAIK, the inbox has, by default, APPEND permissions. APPEND allows you to use POST and PATCH, but not READ. WRITE perms imply READ, APPEND perms do not. This makes sense if you think about it - we want anyone to be able to write a message to us (append it), but only we ourselves should be able to read it.

@WhyINeedToFillUsername
Copy link
Author

Thanks for the quick reply. I'm not sure we're talking about the same stuff - permissions for CRUD operations on inbox are alright, AFAIK.

I am talking about the WebSockets API. Anybody, without any auth, can subscribe to anyone's inbox or any other resource: https://github.com/solid/solid-spec/blob/master/api-websockets.md#subscription. So for example I can subscribe to YOUR inbox and get WebSocket event when YOU get a (private) message (but I cannot read the message content, that's ok).

I haven't tested it on other resources, but if it works the same way, I could maliciously subscribe to someone's (imaginatory) resources like /medical/myCancerRecords or /bank/records and get notifications when there's CRUD on those resources.

But if you say sending the WS events depend on APPEND permissions, then it is ok I guess. That should be in the WS spec I believe.

@jeff-zucker
Copy link

Yes, I think my point may be a red herring for your question. You can't tell if someone has APPEND perms just from a 401 on a GET, but on the other hand someone without READ perms should not be getting notifications.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants