While practicing & testing the Solid, I’ve noticed that Solid has an insecure authentication mechanism. I am going to explain this issue with a scenario, then I will give a proposition to fix it.
app-x copy user-a’s session information from localStorage, then sends to hacker-x’s e-mail.
hacker-x opens https://user-a.pro-a.net then pastes user-a’s session information to localStorage.
Consequently, hacker-x signed-in as user-a (the data owner).
Those steps can be tested without a client-app of course. That is just for figuring out as a real scenario. To test this issue, you can basically copy and paste the localStorage data.
Proposition
To fix this major security issue, authentication tokens should be generated domain-based. Thus, one session is going to be related to just one domain, eventually hacking will be blocked.
I am also concerned about this potential misuse. It feels like an internet full of applications for downloading without antivirus.
That’s why I think giving limited access is important (as this would limit the potential data leak), but it doesn’t seem like the one and only solution, more like a part of it.
Regarding your proposition: Is there a way to securely verify the origin domain of a request? As far as I know, this could easily be faked too. (e.g. see this SO question)
If the connection is performed over HTTPS (secure HTTP), the domain should be trustworthy as far as I know (see https://tools.ietf.org/search/rfc2818#section-3.1). Perhaps Solid may force the Solid-enabled client applications to have a secure connection. After this precaution have been supplied, my proposition can be implemented.
The section you’ve linked to is about verifying the server (i.e. the one who gets the request) and not the sender of the request. And in section 3.2 they say
Typically, the server has no external knowledge of what the client’s
identity ought to be and so checks (other than that the client has a
certificate chain rooted in an appropriate CA) are not possible.
Also in the SO question I’ve linked to before, they claim, that “[…] it works correctly with HTTPS”.
Please correct me if I misunderstood something, I don’t have much experience in security related topics
What do you think about a browser extension which restricts http(s) requests only to specific domains for apps?
For instance, a filemanager only needs to send requests to the pod, there’s no need for it to send something to a third party. So disabling requests to other domains shouldn’t restrict the functionality of the app, while making sure no data is leaked. When a third party request is made it could ask the user to allow/reject it.
To make it secure we’d need to consider some other options which could share data (cookies, iframes/image-links, …), and I’m not sure if it’s theoretically possible to block all ways in which data could be shared. But do you think that’s worth looking into?
(And it would obviously only work, when the user installs the addon. So it’s just a “bonus” to the security)
I agree that limiting where apps can send data is something we could use. I put this argument forward on the SAFE forum because I think it has some benefits.
One is that it makes it clearer to the user what an app is doing with data - if the app has to ask permission to send it somewhere unusual (outside your pod for example).
Another is that having to give permission will be seen as a negative feature of an app. We don’t like being pestered! So this creates a pressure on developers to minimise this, and to not send data anywhere that isn’t important enough to bother the user - or risk the user dumping the app for something less bothersome.
Do you know if there’s already a discussion about this somewhere or if someone has started working on it? Because a tool to limit outgoing requests seems like an important feature, I would be happy to add my two cents on this and maybe also help developing if I an be of use.
@RubenVerborgh Could you explain your point a bit more, on why you think that browser extensions shouldn’t be used for security issues?
From my point of view, browser extensions could be used to add an additional layer of security to Solid (but by no means be a crucial part of it). For instance the request blocking extension I’ve outlined before could be used to make sure data doesn’t get into the wrong hands easily. As we can’t expect all users to use such an extension, the basic security model still has to be built well, but I don’t see why we shouldn’t add browser extensions for extending data control.
I agree with you. But it’s applicable only for non-social applications. From a futuristic perspective, perhaps client applications can have a type (social app, individual app, etc.) that indicates their behavior. Then, browsers can restrict/allow applications to send requests to third parties.
