💾 Archived View for rawtext.club › ~sloum › geminilist › 001736.gmi captured on 2020-09-24 at 01:40:49. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
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.