💾 Archived View for rawtext.club › ~sloum › geminilist › 001735.gmi captured on 2020-09-24 at 01:40:52. Gemini links have been rewritten to link to archived content

View Raw

More Information

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

<-- back to the mailing list

CSRF in Gemini

Francesco Gazzetta fgaz at fgaz.me

Tue Jun 16 10:29:12 BST 2020

- - - - - - - - - - - - - - - - - - - 

On Mon, 15 Jun 2020 17:05:33 +0200Felix Queißner <felix at masterq32.de> wrote:

I think one solution would be to force clients to remove queries from
all URLs. It's not a really elegant solution and makes CGI stuff
harder to implement, but will prevent a lot of URL-fuckery.

That coul be a good and clean solution, if we get microbotany, gus, etcto move the stuff they put in the query to a path fragment. Too badthis means that it's no longer possible to use cgi for that stuff.

While writing this, i got the following idea (which seams reasonable
to me): Specify that a response to INPUT MUST be passed with a
query-parameter "?input=…" where "…" is the data from the user. The
data is fully urlencoded with all forbidden characters(space,?,=,…)
replaced with their percent-encoding.
Also specify that clients SHOULD remove the "input"-parameter between
redirects and in documents using the gemini-scheme.

Less clean, but preserves cgi functionality and it's stateless! I likethis

This allows us to prevent passing accidential or malicious data via
redirects, but doesn't help against a spam-bot that targets a site
directly. It also makes client implementation a bit harder.

Eh, the spam problem is a problem on its own anyway, and I probablyshould have made a different example in my article.