💾 Archived View for alpha.lyk.so › gemlog › 010-use-csrf-tokens.gmi captured on 2024-05-12 at 15:11:05. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-04-28)
-=-=-=-=-=-=-
If you're going to implement a service on Gemini, you should probably use CSRF tokens for paths that produce writes. A user on Geddit suggests requiring client certificates:
This does not solve the problem. A user's browser may be set up to use a client certificate for all requests to a given server or URL (and all its sub-URLs). The way this problem was solved on the Web, and the way which likewise makes the most sense on Gemini, is to generate a random, single-use, time-limited string which must be submitted with any request to any URL which mutates state on the server.
Station is the only service I've seen so far on Gemini that does something like this, though the implementation isn't exactly correct. The "CSRF string" is just the first four letters of the user's client certificate, which is better than nothing, though it does leave open the possibility of CSRF attacks delivered via spear-phishing if the client certificate fingerprint gets leaked anywhere (e.g., if the attacker happens to run a Gemini service as well). (There's also the risk of an attacker succeeding with a blind guess, but they'd be expected to succeed in only 1 in 65,536 clicks.) Gemini is likely not yet at a stage where this sort of spear-phishing attack is likely to take place, let alone be of any consequence, but the security implications of design choices should be noted, in my opinion.