web-access-control-spec
web-access-control-spec copied to clipboard
solid
Circumventing Origin restriction with proxies
https://github.com/solid/web-access-control-spec#referring-to-origins-ie-web-apps
When a compliant server receives a request from a web application running in a browser, the browser will send an extra warning HTTP header, the Origin header.
What about cases where 'malicious' app running in a browser uses a proxy to change the Origin header? I think it might work differently with WebID-OIDC and WebID-TLS.
Malicious app still would need to know which 'allowed' origin to use but let's consider scenario where it knows that 'allowed' origin and proxy sets header to it.
For webid-oidc this is not a problem, because the token that the web app obtains is specific to both webid and app origin. A web app can only obtain a token that is tied to its own origin.
For webid-tls, I don't know, I'll find out!
Do you refer to aud field in ID Token? I don't know how exactly NSS uses it to verify client's origin, maybe @dmitrizagidulin can link to relevant code. I think of a case where NSS acts just as a Resource Server and app/client gets ID Token from some other OP which as I understand handles the client registration.
This is a reason to move towards client-id based origin tokens. User client id as the origin
https://github.com/solid/webid-oidc-spec/issues/12 should address it, I will close this one once it gets resolved
I have lots of OIDC context, but limited web-access-control.
I threw out a straw man of removing from the spec this (since it might be adding a MUST that allows unauthorized access via proxy)
When an Origin header is present then BOTH the authenticated agent AND the origin MUST be allowed access
Dmitri mentioned that would face resistance as such. But a better alternative should be developed, then this language removed.
A followup proposal that should be less controversial is to add a warning to the spec right before that MUST
WARNING: This normative language is at-risk of removal because it can be exploited. See this issue (link needed) for progress on a safe alternative.
If a bad proxy does not forward the Origin header, then the CORS security is broken by the bad proxy. Don’t use or implement bad proxies. This does not change WAC.
I'm describing here possibility of application running in a web browser intentionally using properly implemented proxy which by design allows it to advertise whatever Origin party providing the application wants that application to claim on requests. Party providing (hosting) the application, is the same party which controls the proxy.