S02:2023 - User Consent and Interface Issues 🤝

Overview

Users rely on MetaMask to safeguard their cryptographic keys and identity, expecting the platform to rigorously enforce authoritative security standards and execute actions solely with explicit user consent. Additionally, users place trust in the accuracy and reliability of the information presented by MetaMask. The acknowledgment that this trust is not universally guaranteed highlights the significance of User Consent and Interface Issues, positioning it #2 in the Snap Security Top 10.

Description

This section highlights the significance of obtaining clear and informed user consent while emphasizing the importance of an intuitive and secure user interface to prevent user interface related vulnerabilities and enhance the overall user experience.

User consent and interface issues encompass the challenges associated with obtaining explicit permission from users for specific actions, as well as addressing potential pitfalls in the design and functionality of the extension's user interface. Failing to obtain proper consent or presenting confusing user interfaces can lead to unintentional user actions, potentially resulting in security vulnerabilities, financial losses, or diminished user trust.

• Secret data is directly exposed to a dApp or 3^rd party service.
• The Snap allows a dApp to perform critical actions without user consent (i.e. sign transactions).
• A dApp can bypass user consent or instruct the Snap to not to show dialogs that request for consent.
• Information displayed on user dialogs is not in human readable form.
• Information displayed cannot be individually verified.
• Information displayed is solely based on data provided by a dApp (not considered trusted).
• A dApp can change Snap storage without user approval.
• A request for consent does not display the dApp / origin which can be confusing in case of multiple origins requesting user interaction at the same time (race condition).
• User wallet addresses are enumerateable by a dApp without user consent.
• Information displayed is inaccurately displayed or truncated (e.g., 0.1 rounded to 0.0).
• Privacy preserving functionality is completely missing.
• State-changing RPC method handlers are executed without user consent (silent functionality).
• Dialogs display misleading information.
• Dialogs display information providing a false sense of security.
• Snap UX/UI undermines established MetaMask UX/UI patterns and user flows.
• User account used for signing data is not displayed on the confirmation dialog.
• Users are not in control of data stored to the Snap storage (i.e. settings).

How to Prevent

• Ensure the extension only operates on explicit user consent.
• Stick to established and secure UX/UI concepts that users are used to from MetaMask dialogs.
• Implement clear and concise consent mechanisms.
• Design an intuitive and user-friendly interface that minimizes the risk of users making unintended or erroneous transactions.
• Avoid cluttered or confusing layouts that may lead to user errors or misunderstandings.
• Implement robust transaction confirmation mechanisms, requiring users to review and confirm critical actions, such as fund transfers or sensitive settings changes.
• Provide guides, or tutorials to help users navigate and understand the extension's features.
• Protect the user and sensitive information, in transit, on screen, and at rest.
• Clearly communicate what data is processed and stored.
• To protect user's privacy it is suggested to ask the user for consent to reveal their account address to the dApp the first time a dApp requests so.

Example Misuse Scenarios

Scenario #1: Opaque Signing UI

The dApp requests to sign a message with a user account managed by the Snap. The Snap allows a dApp to select the account when requesting signature. However, the Snap does not display the user account under which the message is signed. A malicious dApp may, therefore, trick the user into signing with an account they did not intend to sign the data with.

Scenario #2: Unauthorized Transactions

Lack of clear user consent or confusing interface elements may lead to unintentional user approval of unauthorized transactions.

For example, a Snap provides an RPC API to sign transactions for ThorChain that does not request explicit user consent upon signing allowing a dApp to silently sign arbitrary transactions in the name of a users account.

Scenario #3: Account Enumeration

In this scenario, a Snap provides an RPC API that returns a user's wallet account. However, the Snap fails to ask the user for consent that the dApp is allowed to access particular wallet user account addresses. For example, in MetaMask, users would explicitly select which account addresses are visible to a specific dApp.

This is a privacy concern where the application might silently enumerate user accounts without proper consent.

Scenario #4: "Shoulder Surfers"

In this scenario, the Snap allows a dApp to reveal a private key to the user, as returning it to the dApp is highly discouraged.

However, the Snap displays the private key without a password visibility toggle that implements a click-to-reveal pattern accompanied with a disclaimer text. This can be problematic if the user is in a public environment for instance.