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
---
Previous in thread (25 of 27): 🗣️ Oliver Simmons (oliversimmo (a) gmail.com)