💾 Archived View for gemini.bunburya.eu › newsgroups › gemini › messages › slrntgjj1v.4p4.mbays@ma.sd… captured on 2024-08-18 at 17:20:00. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
From: mbays@sdf.org
Subject: Re: Gemini sessions and CSRF
Date: Sat, 27 Aug 2022 07:48:15 GMT
Message-ID: <slrntgjj1v.4p4.mbays@ma.sdf.org>
In comp.infosystems.gemini, you wrote:
CSRF is a very primitive kind of attack. For example on the page
gemini://eviljoe.net/ the website owner can trick you to open a link on
an external page that invokes an action [...]
It is obvious then that using client certificates present a security
risk that needs to be addressed today.
This was discussed before, and the conclusion at least some of us
reached is that it should be addressed in clients by preventing any
certificate from being applied to requests generated by such
"cross-site" links (unless the user explicitly says it should).
We have a neat way to determine what should count as a "cross-site"
link: as explained in the gemini spec, each client certificate in use is
associated with a "scope", a subtree of URLs where it will be used. So
a certificate which is in use at URL1 should also be used in a request
to URL2 generated by following a link from URL1 if and only if URL2 is
in the scope of that certificate. In all other cases, no certificate
should be used at URL2 without explicit user consent.
Parent: