💾 Archived View for rawtext.club › ~sloum › geminilist › 006942.gmi captured on 2023-09-08 at 16:46:53. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
nervuri nervuri at disroot.org
Mon Jul 19 12:59:49 BST 2021
- - - - - - - - - - - - - - - - - - -
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 afterputting this rule in code form [1], I came away wanting a more verboseand precise formulation. It may seem overkill, but I think it's worthit 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 candecide whether to add this and what wording to go with.
[1] https://gitlab.com/gemini-specification/protocol/-/issues/37#note_629384688