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

Solid sends WS messages on private resources without authentication #232

Description

@WhyINeedToFillUsername

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.

Activity

  1. jeff-zucker commented on Feb 25, 2021

    @jeff-zucker
    Member

    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.

  2. WhyINeedToFillUsername commented on Feb 25, 2021

    @WhyINeedToFillUsername
    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.

  3. jeff-zucker commented on Feb 25, 2021

    @jeff-zucker
    Member

    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 join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions