💾 Archived View for rawtext.club › ~sloum › geminilist › 006879.gmi captured on 2023-11-14 at 09:01:33. Gemini links have been rewritten to link to archived content

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

Malicious Links

Jonathan McHugh indieterminacy at libre.brussels

Fri Jul 9 23:50:40 BST 2021

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

Interesting concern.

What if a delete process required visiting (sequentially) two links?:* Visiting example.com/delete* Visiting example.com/delete/confirm

Would that permit users to realise somethings awry prior to making a fateful error?

====================Jonathan McHughindieterminacy at libre.brussels

July 10, 2021 12:26 AM, nothien at uber.space wrote:

In Gemini, the restriction that information can only be sent to a server

by performing a request is considered a feature. However, this can

backfire by removing the need for user interaction, even when it is

absolutely necessary. Below, I provide an example to show why this

feature, combined with the existence of malicious links, can prevent (or

at least hinder) the sole use of TLS certificates in account-based sites

on Gemini.

Consider a website, gemini://example.org, where users can set up

accounts. It uses TLS certificates for authentication and provides

important settings through the Gemini interface. For example, one can

delete their account by visiting a certain URL: perhaps

gemini://example.org/account/delete. Although this makes sense, you may

already begin to understand the problem at hand.

Malicious Gemini pages (or parts thereof) can contain links to such

locations. Depending upon the user's Gemini client configuration, it

may not show them the URL they are going to (e.g. Amfora, I think), and

they may accidentally delete their account at gemini://example.org (or

perform any other action involuntarily) this way.

Note that simple workarounds such as responding by asking the user to

type 'YES' can be avoided trivially, by adding the 'YES' to the query

string in the URL of the malicious link.

One possible workaround is to require the user to provide their password

(through a response 11) for every such action. Presumably, the attacker

doesn't know the user's password, and so cannot craft a URL which would

delete the user's account without interaction from them. Sites would

have to re-state the action being performed within the prompt attached

to the response 11, and give context (so the prompt may look something

like "Are you sure you want to delete the account at

gemini://example.org? Type in your password to continue."). However,

if the user is performing many actions which require password

verification, this is going to get irritating. In addition, it forces

sites into using and storing passwords, even when they use TLS

certificates.

Another workaround is to require the user to provide a randomly

generated string. For example, upon visiting

gemini://example.org/account/delete, the user is requested to type in

some words that were generated at that moment ("correct horse battery

staple") to authorize the action. This removes the need for a password

in addition to the TLS certificate, but forces sites to keep track of

the random words for each user whenever they request such an action

(this functionality will likely have to be implemented by hand, and

there are complications like timeouts to consider). This prevents

attackers from crafting the necessary URL, but once again performing

account-related actions through Gemini would become irritating.

It would also be possible to avoid this issue by using a special URL

format when sensitive input needs to be included. Sites requiring

authorization (even just a 'YES' string) could use the sensitive input

response, and clients would not allow the sensitive input string to be

automatically provided (instead, the user would be required to type it

by hand). This provides a minimal level of necessary user interaction.

Although it still suffers from the repetition problem of the above

workarounds, it seems to reduce the amount of work necessary, and

better share it between server, client, and user. However, it would

necessitate a breaking change in protocol (or, perhaps, a new status

code and convention for 'sensitive query strings').

The reason that HTTP/HTML does not suffer from this problem is twofold.

Firstly, HTML is interactive, and so whenever such an action is

performed, the user can be interactively requested to confirm their

intention. Secondly, when the action is performed directly (e.g. by

using HTTP POST to the relevant URL), the attacker doesn't have access

to the necessary cookies to authorize the action. TLS certificates are

problematic in comparison because they apply for all interactions with

the site, and so automatically authorize any interaction; cookies for a

certain site are only available to the HTML/CSS/JS of that site, and so

the site can interactively verify the user's intention before

authorizing the action. The access control with cookies also avoids the

repetition problem, and allows users to authorize once to perform

multiple actions.

With any of the above workarounds, account management on sites through

Gemini becomes difficult, both for hosters/admins and for users. In

fact, this extends to just about any account-based interaction with any

site; for example, sites where comments can be uploaded are affected,

because a malicious link can cause an unpleasant comment to be

involuntarily submitted.

What does the Gemini community think? How big of a problem is this?

Are there any other feasible workarounds? Which major (and minor) sites

are affected? Does this call for some sort of change in protocol?

~nothien

P.S: I'm not sure what ML category this fits into. [spec], maybe?

[tech]? No clue.