specification
specification copied to clipboard
Discuss security considerations for fetching and processing external documents
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.).
Great point.
(I would add the /proxy
endpoint to that list.)
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).
Issue description updated to include WebID/OIDC example considerations.