💾 Archived View for rawtext.club › ~sloum › geminilist › 001736.gmi captured on 2020-10-31 at 02:29:17. Gemini links have been rewritten to link to archived content

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

CSRF in Gemini

Francesco Gazzetta fgaz at fgaz.me

Tue Jun 16 10:35:20 BST 2020

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

On Tue, 16 Jun 2020 00:11:35 +0200Peter Vernigorov <pitr.vern at gmail.com> wrote:

This type of attack impacts more than just endpoints that rely on

query parameter. For example, one can delete their astrobotany plant

simply by getting redirected to /app/plant/harvest/confirm (although

that is not strictly deletion). If a certificate is already activated

for this site, then this will not help stop the attack.

I think that's also a different problem. Such endpoints should IMOrequire input from the user, like "Type yes to confirm". Or there couldbe an additional 1x code for requesting a simple yes/no confirmation.This code could easily fallback to 10, by having the buttons send "yes"or "no" and the question say "Do you confirm? Type yes/no".

However, the difference I see between HTTP/HTML and Gemini is that

this attack is not happening in an invisible iframe/xhr request, but

in plain sight of the user. Once they are redirected to any of the

impacted pages, they will see a message from server informing them of

their actions. "you posted a comment", "you harvested/deleted your

plant". Perhaps an easy workaround is to let user undo their action?

"you posted a comment, would you like to undo?" This has an additional

positive side effect of an easy undo of human errors, in case the

comment was submitted prematurely, or contains an error.

Undo is not always easy to implement though (strawman: you launched anuclear missile. undo?), and one has to remember to do it for everypage, much like remembering to escape string-concatenated sqlstatements.