Peter Vernigorov pitr.vern at gmail.com
Mon Jun 15 23:11:35 BST 2020
- - - - - - - - - - - - - - - - - - -
This type of attack impacts more than just endpoints that rely onquery parameter. For example, one can delete their astrobotany plantsimply by getting redirected to /app/plant/harvest/confirm (althoughthat is not strictly deletion). If a certificate is already activatedfor this site, then this will not help stop the attack.
However, the difference I see between HTTP/HTML and Gemini is thatthis attack is not happening in an invisible iframe/xhr request, butin plain sight of the user. Once they are redirected to any of theimpacted pages, they will see a message from server informing them oftheir actions. "you posted a comment", "you harvested/deleted yourplant". Perhaps an easy workaround is to let user undo their action?"you posted a comment, would you like to undo?" This has an additionalpositive side effect of an easy undo of human errors, in case thecomment was submitted prematurely, or contains an error.
On Mon, Jun 15, 2020 at 5:05 PM Felix Queißner <felix at masterq32.de> wrote:
Hey!
I just wrote down a few thoughts about cross-site request forgery in Gemini:
Good read! I thought about that as well…
CSRF protection via non-native nonces is ugly, can we do better than
the web?
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. I'm also always
scared when clicking links in interactive things, because double
postings are really easy to achieve with the query appended to URLs.
Hitting refresh in your browser to see new posts? You create a new post
in the guestbook!
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.
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.
Regards
- xq