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ā
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
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 ?
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.
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.
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?
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.
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 ^^
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.
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.
@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
?
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.
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.