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