Require authentication on proxy endpoint

[csarven]

Am away from proper keyboard at the moment to follow up closely.

I thought there was an issue or discussion somewhere already on this but if this is a duplicate issue or inapplicable, feel free to close.

The corsProxy URL must require authentication so as to not expose am open/public proxy.

@bourgeoa

[bourgeoa]

@csarven @jeff-zucker @zg009

The CorsProxy is implemented in

node-solid-server/lib/handlers/cors-proxy.js

Line 66 in f5652f3

app.get(path, extractProxyConfig, corsHandler, proxyHandler)

3 middlewares are called :

• path is the proxy path. By default /proxy
• a NSS express middleware extractProxyConfig
  

  node-solid-server/lib/handlers/cors-proxy.js

  Lines 69 to 70 in f5652f3

  	// Extracts proxy configuration parameters from the request
  	function extractProxyConfig (req, res, next) {

  
  checks are made that the destination url is Valid and that the is not in unauthorized list else return 400

We can implement in this middleware some more controls about

1. is this an authenticated request ?

   • to whom shall these parameters depend on : the pod provider, the pod owner, the authenticated user ...
   • how do we check for authenticated request ?
     • Is there a way to know who is authenticated ?

2. is the destination Url allowed ? white/black list

   • the list location depends on the answers on 1.
     • This could be on server code
     • on the pod like /proxy/whiteList.ttl
     • on/through the WebID document of the authenticated user

There is a need for a better understanding of the use cases and the security level expected.

[jeff-zucker]

In #111 @csarven writes : "CORS is PITA (Pain in the Ass) and for Solid applications to take advantage of resources beyond those on a Solid server or a server that properly implements CORS, there needs to be use of a proxy. Otherwise, a whole category of use cases for Solid applications is a non-starter. Again, dokieli has plenty of experience on this - resources could be anywhere. And undoubtedly other applications have run into similar shortcomings"

As mentioned previously, several of my applications are up against the same shortcomings of CORS as dokeli. Basically, without a proxy, entire realms of data are denied to us. I do not think we need further evidence that a CORS proxy for reading is needed. I do not see a need for writing via a proxy. If we allow writing via the proxy, then yes, for sure we need controls. But for just reading, why would we need to know that a user is authenticated or anything about their destination? Whitelist destinations? Why? How? Forbid proxying for non-RDF data? - that cuts off huge amounts of data that become unusable by client applications.

Even if we do eliminate or restrict remote server proxying, the self-host option can benefit from proxying and in the single-user case there is absolutely no need for restrictions of the kinds proposed.

[csarven]

I'm not sure if corsProxy and authProxy ( https://github.com/nodeSolidServer/node-solid-server/blob/main/lib/handlers/auth-proxy.js ) needs to be separate things. The proxy "resource" (service or endpoint or whatever) should be CORS enabled and require authn/z. So, 1) corsProxy may need to be depreacted and 2) authProxy brough up to speed? I don't know the inner details of these libs.

[csarven]

@jeff-zucker , but even for reading, personal or otherwise public (unauthenticated) proxies pose a concern for misuse because the URL would be known to anyone. That can be anything from random bots poking at it, people using someone else's network/bandwidth, to downright retrieval of content against the law (in a nutshell). There may be ok/safe/controlled/narrow cases for the proxy URL to be used without authentication, but once the URL is known, it becomes a concern.

I just want to highlight that this is probably step one on at least limiting use to only authorized users. For multi-user setups / community servers (where anyone can sign-up) that needs separate / additional layers of ensuring if and how the proxy or proxies can be used. That cuts into ToS and stuff, and having some kind of moderation - which gets complicated in and itself if it is anything beyond scripts differentiating allowed/disallowed use. I'm not an expert in this area. Just saying that it needs some care and more eyes, and possible guidance to server admins / owners.

[zg009]

@csarven I'm new to CORS proxies myself so I have to ask: If it's being provided through a Solid-compliant resource server as a service, what would be needed beyond an authorization check for an authorized request through the proxy? Or are my assumptions about the flow of this wrong?

[csarven]

Authn/z would be the basic coverage for the endpoint. There may be other criteria for the target resource that's to be fetched, as mentioned above e.g., disallow making requests to certain origins (for obvious reasons) and that can be maintained by storage owner or admin configuring the server (possibly use shared lists). There can be some basic settings to protect the individuals making use of the proxy as well as the owners of the (proxy) URI.

[jeff-zucker]

@csarven - currently NSS provides its proxy from https://solidcommunity.net/proxy, i.e. the root of the server, not from a user storage within the server. Are you suggesting that each storage have its own proxy e.g. https://me.solidcommunity.net/proxy? This would allow the kind of per-user configuration you mention as well as putting its access under WAC control.

[csarven]

I think proxy endpoint/service is not like a typical resource that appears in a storage where its state can change nor meaningful to discover through containment. Of course a proxy could be "part of" a storage but I think it is categorically different than resources as well as auxiliary resources in a storage.

This probably cuts into spec'ing but we can still discuss here. A quick and dirty sketch of what I'm thinking:

• Proxy (/proxy) should be CORS enabled (otherwise its utility may not be great).
• Proxy state must not be changeable, so no writing from HTTP (no PUT, PATCH, DELETE) by anyone (including the owners).
• Proxy should only allow safe requests, so only read (GET, HEAD, OPTIONS)
• Proxy may allow POST but it can't have side-effects (and not particularly cache-friendly)
• Proxy may allow CONNECT (and this gets complex, interesting, and wild, but it would potentially open up the possibility for write requests through the tunnel to its destination; it would really need to be super secure and probably limited to owners).

---

So, https://example.org/proxy (as with current NSS) seems fine to me provided authenticated fetching, and the access subjects can be owners (in a single-user case), and I suppose https://proxy.example.org/ could be a possibility too for a single-user setup, and its root / wouldn't be a Solid storage. For a multi-user setup, all owners of a given instance can access it, e.g., https://guinan.example.org/proxy. IMO /proxy shouldn't be listed in containment however this is implemented. Requests to /proxy should be logged, and users of it (the owners) should be aware. So, the basic content for /proxy should state that it is being logged and that some requests may be limited (some IPs, domains, or URLs being disallowed depending on server set up), and probably some other minimal information.

It should not be assumed that the proxy URL is a secret URL. Applications need to be able to navigate to it, if not already known or findable by other means.