Malicious Links

[nervuri]

On Fri, 2021-07-09, nothien@uber.space wrote:
> What does the Gemini community think?  How big of a problem is this?
> Are there any other feasible workarounds?  Which major (and minor) sites
> are affected?  Does this call for some sort of change in protocol?

See previous discussions:

gemini://gemini.circumlunar.space/~/fgaz/posts/2020-06-15-csrf-in-gemini/
- https://mailing-list-archive.gemi.dev/www/2020/001698.html

gemini://gemini.circumlunar.space/users/solderpunk/cornedbeef/a-vision-for-gemini-applications.gmi
- https://mailing-list-archive.gemi.dev/www/2020/001747.html

Takeaways:

Server-side: mandate client certs for requests with non-trivial
consequences and use nonces (CSRF tokens) to be extra-safe (see the
first link).

Client-side: never use a client certificate when following a link from
outside the client certificate's scope, as defined in section 4.3 of the
spec.  This rule could be added to the spec itself.  Here's how the
scope is defined:

> A client certificate which is generated or loaded in response to such a
> status code has its scope bound to the same hostname as the request URL
> and to all paths below the path of the request URL path. E.g. if a
> request for gemini://example.com/foo returns status 60 and the user
> chooses to generate a new client certificate in response to this, that
> same certificate should be used for subsequent requests to
> gemini://example.com/foo, gemini://example.com/foo/bar/,
> gemini://example.com/foo/bar/baz, etc.,

Another client-side takeaway: consider Solderpunk's idea of a
"containerised" client, exemplified in [1].

Such client-side precautions should cover most cases of CSRF, except, to
quote Solderpunk:

> It is not foolproof - it cannot protect against application-internal
> CSRF attacks, e.g. some kind of multi-user application where one user
> can post text/gemini content which is rendered by another user of the
> same application.

Nonces (CSRF tokens) should be used in such instances.

[1] https://mailing-list-archive.gemi.dev/www/2020/001771.html