Insecure Solid Authentication Mechanism


#1

Insecure Solid Authentication Mechanism

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.

Assumptions

Scenario

  1. user-a sign-in to app-x using their credentials for https://user-a.pro-a.net/profile/card#me
  2. app-x copy user-a’s session information from localStorage, then sends to hacker-x’s e-mail.
  3. hacker-x opens https://user-a.pro-a.net then pastes user-a’s session information to localStorage.
  4. 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.


#2

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)


#3

Thank you for feedback. According to Host section in the RFC of HTTP: Message Syntax and Routing, a client request should contain the HOST header field. Therefore, it should be easy to get the origin domain.

Bonus: See for getting hostname in Express https://expressjs.com/en/api.html#req.hostname


#4

Yes, but only because a header must be sent that doesn’t mean it’s not altered. And I do believe that changing the host header is possible without much effort (e.g. this seems like it should work: https://stackoverflow.com/questions/3390549/set-curl-to-use-local-virtual-hosts/10218482#10218482). So I believe its sadly not trustworthy.


#5

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.


#6

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


#7

@keislamoglu Thanks for posting. We are aware of this situation: at the moment, users can only give full authorization to apps, not partial authorization. So authorizing yourself with an app is indeed given that app full access, so it should not be done with apps you don’t trust.

Here are some other similar scenarios that show the trust level of apps:
– if I log in to a malicious app X, X can copy all of my data and send it elsewhere
– if I log in to malicious app X, X can change the permissions such that hacker Y has read-write access but I do not

There are a couple of mitigation mechanisms:
– the localStorage credentials are only valid for a limited amount of time (token expiration) => this is already the case today
– the localStorage credentials could be app-specific => not yet the case

Also see https://github.com/solid/solid-auth-client/issues/109

The definitive solution here is about restricting what apps can see, and restricting the usage scope of tokens.


#8

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)


#9

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.


#10

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.


#11

Ultimately, we could use browser support for identity. Extensions can be used in the short term, but then they should only offer increased usability, not basic features such as security.


#12

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


#13

Extensions are typically installed by more tech-savvy people, so we would leave people who are most vulnerable less safe. We need to strive for a completely secure model within the browser.


#14

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.