Malicious Links

[nervuri]

On Fri, 2021-07-16, Oliver Simmons wrote:
> How about the following?
>
> "A client MUST NOT make a request to a URI in the scope of a client
> certificate outside the current scope, unless the user explicitly
> allows the request. The client SHOULD present the full target URI to
> the user."

Yes, I think I prefer the "MUST NOT ... unless ..." structure, but after
putting this rule in code form [1], I came away wanting a more verbose
and precise formulation.  It may seem overkill, but I think it's worth
it for the sake of clarity:

 Since each client certificate is bound to a scope, we define cross-scope
 requests as requests made by interactive clients starting at URI 1 and
 going to URI 2, where the following conditions are true:

 * URI 2 is in scope of an active client certificate;
 * URI 1 is not in that same scope;
 * the user did not explicitly input URI 2.

 Such requests can occur when following a link on a page or following
 one or more redirects.

 An interactive client MUST NOT use a client certificate when making a
 cross-scope request, unless the user explicitly allows it after being
 shown the full target URI and an indication of what client certificate
 would be used to connect to it.

 This is to protect against Cross-Scope Request Forgery (CSRF), a type
 of attack in which the user is tricked into executing unwanted actions
 in a Gemini application in which they’re currently authenticated - for
 example by following a redirect from
 `gemini://malicious.org/kittens.png` to
 `gemini://gemini.forum/account/delete`.

I would add this to the end of section 4.3.

I'll leave it at this.  When they find the time, Sean or Solderpunk can
decide whether to add this and what wording to go with.

[1] https://gitlab.com/gemini-specification/protocol/-/issues/37#note_629384688