💾 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

View Raw

More Information

⬅️ Previous capture (2023-01-29)

-=-=-=-=-=-=-

Re: Gemini sessions and CSRF

Message headers

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>

Message content

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.

Related

Parent:

Gemini sessions and CSRF (by Cyrus Valkonen <cyrus.valkonen@gmail.com> on Fri, 19 Aug 2022 19:19:58 +0200)