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. 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. 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
---
Previous in thread (3 of 11): 🗣️ Felix Queißner (felix (a) masterq32.de)
Next in thread (5 of 11): 🗣️ Sean Conner (sean (a) conman.org)