Security issues with bogus WebID documents to be considered

[RubenVerborgh]

While #13 prevents memory from filling up from WebID documents with a large number of triples, there are still potential attacks to be considered:

• The code 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 OIDC issuers, 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

We might want to mitigate by allowing passing in a custom fetcher, which could include protection mechanisms against the above, while in the future also performing tasks such as authenticated fetch, caching (see #12), etc.

[RubenVerborgh]

@kjetilk/@csarven Do we also want spec advice and/or tests for such attack scenarios?

[matthieubosquet]

I agree with your diagnostic @RubenVerborgh.
Not that I have a ready-made solution. But indeed, having a more Solid-ready fetch function for everyone to use would be great.

Would it maybe be time for a @solid/fetcher-ts project that includes an authn closure, default caching mechanisms, timeout protections, max size, retry mechanism...

As I believe your comment applies to the entire Solid ecosystem of decentralised apps and data.

[RubenVerborgh]

Thanks @matthieubosquet, I incorporated this into solid/specification#21; let's await its resolution.

[matthieubosquet]

This is also linked to: CommunitySolidServer/CommunitySolidServer#907