Disallow invalid Origin values / strip trailing slashes

[angelo-v]

It is a common and frustrating mistake to put a slash at the end of the Origin value (see e.g. https://gitter.im/solid/chat?at=5f201ed23eef7e1ffe3c40b4)

The UI should validate if the value is a valid Origin value, aka Origin: <scheme> "://" <hostname> [ ":" <port> ] (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin)

Especially it should disallow or auto-remove trailing slashes

[acoburn]

It is possibly worth noting that authorization decisions based on incoming Origin headers are very problematic. While I suspect that NSS supports Origin headers as a proxy for identifying apps, I would strongly advocate that any discussion of Origin headers be focused on removing support rather than refining how that support is implemented.

[angelo-v]

Agree, that it's misleading to call this Authorization at all. It is XSS protection

[acoburn]

Even as XSS protection, it's terribly easy to circumvent.

[bblfish]

Even as XSS protection, it's terribly easy to circumvent.

How does one do that?

(note: the whole framework to protect against XSS is quite cumbersome for linked data applications, so it's not one we like to live with. But changing that feature is quite difficult, and suggesting improvements on the W3C groups were not met with friendliness 4-5 years ago)

[acoburn]

Even as XSS protection, it's terribly easy to circumvent.

How does one do that?

Easy. Say you have an app that would ordinarily send Origin headers from https://malicious.com but your Pod only allows apps from https://beneficent.com. Your pod is at https://pod.example/.

What you do is this: you have the app at https://malicious.com send requests to https://malicious-proxy.com (a browser will send the expected Origin header and the appropriate CORS headers are sent back). That proxy strips off the Origin header, replacing it with Origin: https://beneficent and sends a back-channel request to https://pod.example/. The response from https://pod.example/ is passed back to your malicious app via the proxy. This allows any malicious app to masquerade as any app. A simpler variation is to host that proxy on https://malicious.com which would bypass CORS altogether.

XSS is not the issue here. The issue is in relying on the Origin header as a trustworthy application identifier. It is not possible to prevent against apps getting around CORS restrictions, but it is imperative to have an authZ model that doesn't invite spoofing.

[bblfish]

Ah yes, we all have to use proxies in Solid for that use case. It is particularly annoying as one has to do that for accessing public resources and it is so easy to circumvent. I think that is the point I was trying to point out made no sense on those security lists long ago.

[zenomt]

the Origin header can never be trusted when authentication is by an app-controlled token (like an Authorization header). see https://github.com/solid/webid-oidc-spec/issues/33 and especially this comment.

in the case where a cross-origin request is being made and is authenticated with a cookie, and malicious app or its proxy is not at a subdomain of pod, then the cookie won't be sent to malicious or its proxy. the Origin header is safe and appropriate (if not the only way) to identify the app when authenticated with a cookie. however, i expect cross-origin cookie-based authentication to not be the normal case for Solid (that's the whole point of the various "multi-RS" authentication schemes).

[angelo-v]

Lol, I just wanted to urge to focus on the UI issue at hand instead of discussing concepts, but then I noticed we are actually in authentication-panel here and not in the authentication-pane where I actually wanted to place the issue 😲

[angelo-v]

Just created it there, was not aware it could be transfered: https://github.com/solid/solid-panes/issues/240