Discuss security considerations for fetching and processing external documents

[RubenVerborgh]

We should identify all areas where the client or server are instructed by another party to fetch external content, including but not limited to:

• [ ] JSON-LD contexts
• [ ] User profiles by dereferencing a WebID
• [ ] OIDC issuer
• [ ] OIDC endpoints
• [ ] WAC group URLs
• [ ] /proxy
• [ ] …

For such cases, the requesting agent MUST:

• [ ] Carefully consider whether the resource needs fetching
• [ ] Carefully consider the frequency at which the resource is fetched
• [ ] Carefully consider whether it is not being tricked into fetching a resource that the requester cannot or should not access
• [ ] Carefully consider whether the representation is not too big for downloading
• [ ] Carefully consider whether processing a correctly formed representation does not cause any problems
• [ ] Carefully consider whether processing an incorrectly formed representation does not cause any problems

Concrete example: WebID documents for OIDC

As a concrete example, these concerns have been identified for fetching WebID documents in the context of verifying the OIDC issuers:

• Servers can be tricked into dereferencing private documents on the local network, and returning their contents as parse errors
• Servers can wait a long time to reply, causing long/infinite wait times
• Servers can reply with a long/endless list of triples, causing long/infinite wait times
• Servers can reply with a triple containing a huge/never-ending literal, causing long/infinite wait times
• Servers can reply with a long/endless list of OIDC issuers, causing long/infinite wait times

Potential solution suggestions (in addition to listing the above risks)

• We might want to define characteristics for a Solid fetcher/parser, which could include protection mechanisms against the above (and the future also performing tasks such as authenticated fetch, caching, etc.).

[dmitrizagidulin]

Great point.

(I would add the /proxy endpoint to that list.)

[acoburn]

The OIDC server will have a number of endpoints that may be dereferenced during the lifecycle of a request, for example: a JWKS document, the token endpoint, etc.

A sub-category of JSON-LD contexts might include the use of Accept: application/ld+json; profile="SOME-URL" as well as profile documents defined in Indicating and Negotiating Profiles in HTTP (e.g. Accept-Profile).

For this list, I also think it is important to distinguish between remote URLs that are controlled via client-initiated requests (e.g. an incoming JSON-LD document with a remote @context URL or profile negotiation via request headers) and remote URLs that are configured by the server (e.g. a list of trusted OIDC providers).

[RubenVerborgh]

Issue description updated to include WebID/OIDC example considerations.