CSRF protection

A simple rule, roughly equivalent to SameSite=Strict, could be added to the spec to help prevent most instances of CSRF (Cross-Site Request Forgery). The rule can be something like:

When following a URI which is in scope of a client certificate from a page (or via a redirect) outside of that scope, clients MUST prompt the user to activate the client certificate for the target URI.

The scope is defined in section 4.3 of the spec:

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., until such time as the user decides to delete the certificate or to temporarily deactivate it.

In other words, say malicious.org/page.gmi contains this link:

=> gemini://important.site/app/account/delete?yes  Cute kittens!!!

On click, the client asks whether or not to activate the certificate for gemini://important.site/app/account/delete?yes. This helps the user notice the deception.

Same for redirects, such as gemini://malicious.org/kittens.png -> gemini://gemini.forum/account/delete?yes. This covers the situation of [in-scope]->[out-of-scope]->[in-scope], like if the fake link to kittens.png is posted on gemini.forum itself.

This leaves only the [in-scope]->[in-scope] situation vulnerable to CSRF, as explained by 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.

Of course, the rule would not apply to curl-like clients, in which links have to be provided explicitly.

Discussed on the mailing list: https://lists.orbitalfox.eu/archives/gemini/2021/006885.html