CSRF in Gemini

[Francesco Gazzetta]

On Tue, 16 Jun 2020 00:11:35 +0200
Peter 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 IMO
require input from the user, like "Type yes to confirm". Or there could
be 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 a
nuclear missile. undo?), and one has to remember to do it for every
page, much like remembering to escape string-concatenated sql
statements.