-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JWKS endpoint as a high risk resource of the entire dataspace #74
Comments
Hi, I agree that the endpoint is somewhat critical, but so is the entire authorization server. There are some implicit assumptions that we have on the software in use. These include a certain integrity of the executed code. An attacker capable of disabling the Path traversal checks of the relevant Rack Middleware is likely also able to modify the code in a way that uses the existing keys to its liking, hence separating the JWKS endpoint would not be a sufficient protection for the particular scenario you are describing. Additionally, though very specific to your example, usage of the Admin API requires authorization of the client using the I understand that separating the static resources would be a desirable goal for some use cases, but it would not lessen the requirements on proper code integrity and access management configuration. The unprotected endpoints (like If you want to simply separate these resources, you can always configure your reverse proxy (which you should use anyway; Omejdn does not support TLS by itself) to ignore the |
Hi Team,
I've been doing some risk analysis regarding DAPS / omejdn-server and came up with 1 potential risk that might be worth mentioning in
https://github.com/Fraunhofer-AISEC/omejdn-server/blob/master/docs/Setup/Production.md
In general I'm arguing that the jwks.json endpoint is the most critical resource in the entire Dataspace. Why? Because in case someone can add their public key to it, all connectors would trust tokens created by this entity.
Right now, I did not find a way to do this, but I would say there is at least a risk. I think it could happen in combination with another potential issue.
To not make it too abstract, a potential scenario could be the following:
An attacker smuggles in 1 line of code as part of a bigger change:
This disables some very important path param checks. With this, and access to the API, an attacker could do:
In such a case, the path param will be resolved to
../omejdn/evil
and theevil
certificate would be stored in../omejdn/evil.cert
instead of theclients
directory! And consequently being loaded into the JWKS endpoint.Flow
Recommendation
Therefore, I would recommend for production environments to clearly separate the JWKS endpoint - which is rather static content anyway - from the rest of the rather dynamic DAPS environment. I think this lowers the risk of such an attack dramatically.
In some cases, I could even imagine, to independently monitor the JWKS content.
Any thoughts on this?
Matthias Binzer
Robert Bosch GmbH
The text was updated successfully, but these errors were encountered: