💾 Archived View for gemini.bunburya.eu › newsgroups › gemini › messages › tdognu$8pu$1@gioia.aioe.or… captured on 2024-06-16 at 12:44:18. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-01-29)

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

Gemini sessions and CSRF

Message headers

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>

Message content

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

Related

Children:

Re: Gemini sessions and CSRF (by mbays@sdf.org on Sat, 27 Aug 2022 07:48:15 GMT)