💾 Archived View for gemini.bunburya.eu › newsgroups › gemini › messages › tdognu$8pu$1@gioia.aioe.or… captured on 2024-08-24 at 23:56:51. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
From: Cyrus Valkonen <cyrus.valkonen@gmail.com>
Subject: Gemini sessions and CSRF
Date: Fri, 19 Aug 2022 19:19:58 +0200
Message-ID: <tdognu$8pu$1@gioia.aioe.org>
Sessions are necessary in Gemini for: multi variable input, user
creation, login and interaction, captchas and other anti-bot features
required to accept meaningful input from visitors, and other crucial
features of a website.
There are two viable ways to create client sessions in Gemini:
1. By requesting a client certificate and using the TLS hash of it.
2. By storing the session id in the URL directly.
If you have never heard about #1: Gemini has a special feature that
prompts the user in the browser to send or create a personal identifier
(either temporary or permanent). The user just has to press one or two
buttons to proceed. It is basically identical to creating a cookie. You
can then identify that user from your CGI script via the TLS hash
variable and store/retrieve session data from some database.
If you have never though of #2: Using redirect rules of your Gemini
server, you can also create sessions this way:
http://example.com/session-JBOQtGmWhED6L6Dfp7l1Hf/application
This URL is offered like any other and it does not require the user to
click through any dialogues.
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, for example:
gemini://astrobotany.mozz.us/app/killplant
If you had an authenticated account there, this would kill your
Tamagotchi on that site. This is why CSRF tokens are used in HTTP
applications. If the Astrobotany app required the TLS hash to be present
in the URL, ideally encoded in base62, like so:
gemini://astrobotany.mozz.us/app/killplant#JBOQtGmWhED6L6Dfp7l1Hf
Then it would be impossible for an attacker to invoke that action.
CSRF attacks only become really powerful if links are loaded in the
background. And exactly this will happen with Gemini in the future, when
browsers might develop more crawler-alike features that are in line with
the protocol specifications. The first thing that will happen is image
URLs being shown as images directly (already present in some ebook
readers). One step further, all media data, maybe CSV tables, possibly
mini-previews of all URLs if hovered like on Wikipedia. Without changing
the nature of Gemini, clients will seek to enrich the experience as much
as reasonable and possible.
It is obvious then that using client certificates present a security
risk that needs to be addressed today. And that temporary certificates
only yield disadvantages compared to storing a session-token directly in
the URL as shown in #2. It stands to reason then how useful client
certificates in Gemini really are for permanent authentication, compared
to user passwords, and if one might not want to avoid them all together.
Best regards,
Cyrus
Children:
Re: Gemini sessions and CSRF (by mbays@sdf.org on Sat, 27 Aug 2022 07:48:15 GMT)