An application can easily get around apps permissions

Solid Specification
#1

Following our discussion here : User token and security - why SOLID server does not include the origin of the requester in token?

I have done some experiments and found the following :

It is easy for an application to get around the app permissions on a POD and execute actions that are not permitted by the POD owner. Here is to reproduce :

  • The user logs into the application (using solid.auth.client)
  • The user does not grant write permission to the application
  • The application gets the user session information, after login
  • The application requests an access token, with PoPToken.issueFor(…)
  • The application send this token to its server (http request to its server)
  • The server can now make http requests to the SOLID server, keeping origin == null
  • All permissions are granted, even if user did not give access to this app.

The way I did this is by changing a bit solid-auth-client.js this way :

  • Add to top of file :

import PoPToken from ‘@solid/oidc-rp/lib/PoPToken’

  • Add a new exported function :

async issueToken(input : any, session: webIdOidcSession) : Promise<?String> {
const popToken = PoPToken.issueFor(toUrlString(input), session)
return popToken;
}

And my js code of application :

let session = await solid.auth.currentSession();
let popupUri = ‘https://solid.community/common/popup.html’;
if (!session)
session = await solid.auth.popupLogin({ popupUri });
var token = await solid.auth.issueToken(session.webId, session);
// Now send this token to my server

4 Likes
How a SOLID app can have persistent access to all the pods of the users who registered to the app?
Why does NSS (OP) return a wrong audience in the id_token?
#2

Could be an issue on node-solid-server https://github.com/solid/node-solid-server

1 Like
#3

thank you @Smag0
However I will not check further, I am just reporting the behaviour and I am not the security expert, and it is not blocking me for the current work I am doing on SOLID. Should I report this somewhere so that it can be know / taken care of ?

#4

I’m a front dev too but I prefer using a secure backend. So I mentioned your question here https://github.com/solid/node-solid-server/issues/1424

2 Likes
#5

Thank you @Smag0 ! I will follow the thread on github

#6

I just replied to your other thread:

Hi @walter.almeida, I’ve been working on getting an answer for you since you asked; sorry it took so long, and thanks for bringing this up. Since obviously security is a sensitive issue I had to verify with Inrupt’s VP of Trust and Digital Ethics, and then run that by the Solid editors, to make sure the provided info was correct - and obviously they’re all busy people.

Anyway, there is now an answer in the solidproject.org FAQs: https://solidproject.org/faqs#are-apps-vulnerable-to-an-origin-bypass

My personal interpretation (but: that might be wrong, refer to the FAQ for an authoritative answer) is that, indeed, this is a known risk, which is why the Origin-based app-trusting is still labelled as experimental, and people are working on a secure replacement.

1 Like
#7

There is something I don’t understand. The PoP token wraps an ID token. Both have an audience:

  • the id token has the app as the audience;
  • the PoP token has the server as the audience.

The server should check both, so if there is an audience in the id token but the request does not have an Origin header (or the Origin is not correct) then the PoP token should be rejected. Is it not the case?

#8

Reading paragraph https://github.com/solid/webid-oidc-spec/blob/master/application-user-workflow.md I see it is not the case, trivial fix would be to add the sentence:
If the audience of the id_token does not match the value of the Origin header, the RS MUST reject the request with a 403

Similarly, https://github.com/solid/webid-oidc-spec#the-solution-1:

  1. When a RS receives the PoP token, it MUST reject it if the audience of the id_token does not match the value of the Origin header.
1 Like
#9

Yes, seen it, thank you !

#10

And yet @divoplade , in my understanding it will not be enough, would it be ? Browsers automatically add the origin header to the requests and should be ok in this case. However, a browser-less application can just set whatever origin they want. Still, the browser-less application would need to know what is the origin that is expected, but I guess it is easily accessed directly in the token.

#11

Recall that setting the Origin header is not enough, you also need to have a token signed by the oidc provider for the origin you impersonate.

You also cannot lie during the request (pretending you are good-app.com and having a redirect_uri to bad-app.com), because the audience of the signed token is the origin of the redirect_uri: https://github.com/solid/webid-oidc-spec
" Authentication proceeds normally and yields a signed id_token where the aud ience is the client application (represented by the origin of the provided redirect_uri )"

The browser-less application would need to find a token stolen from another origin with better privileges, and impersonate that origin. This requires that the better privileged origin leaks your token back to its server, and then leaks the token back to the other origin. Just as if Google shared your gmail password with Microsoft. I don’t consider this a risk ^^

1 Like
#13

Oh Ok I get it ! with the scenario I was giving, setting origin to null on the browser-less app will not work anymore. Therefore the browser-less app can only set the origin to the origin the token has been signed for, which is OK. Setting any other origin or setting origin to null will not be authorized.

Good, thank you for explanation !

1 Like
#14

Not sure if I understood you correctly, so I’ll just ask:

Checking the origin header ensures that the token only grants the expected permissions, but it does not ensure that someone steals already created tokens from App A and then pretends to be App A, right? If I’m not mistaken, this means that it is vulnerable to XSS, so I would still consider it an important risk.

#15

@A_A the problem was that request with origin header set to null was working, therefore it is easy for a browserless application to send a request overpassing the application security (and my scenario described at the top is the scenario to do this). For what I understand from @divoplade , this is now taken into account and will be corrected
?

#16

This was just my 2 cents suggestion, I am just a new user trying to grasp the whole webid-oidc thing, I have absolutely no power to make this happen except talk about it ^^

There may be more problems I am not aware of (I’d like to understand them though). XSS is still an open problem indeed.

1 Like
#17

According the the Solidproject FAQ, an updated version is planned. I guess that it will prevent your scenario.

Solutions already are planned to revise and replace this experimental use of Origin, in order to evolve security of the trusted app feature.

1 Like
How to give other users access to parts of a user's POD
#18

Hello again,

I have understood a few things lately, and this issue is addressed by the “new” authentication workflow described at https://github.com/solid/authentication-panel/blob/master/oidc-authentication.md.

Indeed, the openid provider now signs a token binding together the application’s origin, the webid of the user, and the public key of the user. So under the new Multi-RS use case, it will be easy to check that the app removed the Origin header.

1 Like
#19

Thank you for investigation and feedback !