Skip to content

S05:2023 - Permission and Authentication Issues 🚷🔑

Overview

At times, Snaps may solicit more permissions than necessary or provide functionality to origins for which it does not actually intend to offer them. The issue of "over-permissioning" has been identified on multiple occasions, leading to the ranking of this vulnerability at #5 in the Snap Security Top 10.

Description

Snaps must adhere to the principle of least privilege, requesting permissions only when genuinely required for specific actions. Interactions should be restricted to the expected origins, and if interaction is anticipated with any origin, the Snap should differentiate. It should provide specific admin functionality exclusively to a trusted and rigorously checked origin, while offering a more general, "safer" API to other dApps.

Typical issues are:

  • Superfluous permissions.

  • Unclear need for permission.

  • Lack of origin restrictions.

  • Production builds allowing access from development hosts.
  • Unsafe wild card origin checks.
  • Lack of separation of trusted origins (admin/settings) from general purpose origins.
  • Lack of authentication of trusted origins.
  • Sensitive information leak or overwrite due to lack of origin separation for user specific Snap settings.

How to Prevent

  • Review requested permissions and adjust the Manifest accordingly.
  • Avoid requesting permissions that are not used.
  • Verify whether the Snap genuinely requires the requested permissions, exploring alternative implementations without such requirements. It should be noted, that, the Manifest is solely applicable to Snap code and there is no need to request permissions that are only used within dApps.
  • Enforce strict origin checks.
  • Distinguish trusted "admin" functionality from general-purpose RPC endpoints by permitting specific actions solely from trusted origins or through authenticated/signed messages.

Example Misuse Scenarios

Scenario #1: Missing origin restriction

In this hypothetical attack scenario, a Snap introduces a distinctive feature demanding user authentication on an external web service. The Snap extends an RPC handler for dApps to manage user credentials. A significant vulnerability arises when the dApp neglects to validate the alignment of the origin setting or credential reading with the trusted origin of the snap provider. Exploiting this oversight, any linked origin gains unauthorized access to the credentials. This creates a severe risk of information leakage or possible overwriting, putting users' sensitive data in jeopardy and rendering the functionality non-operational.

Scenario #2: Superfluous permission

A Snap developer requests endowment:network-access as the dApp utilizes the fetch() API to engage with third-party services. It's crucial to note that endowments exclusively apply to the Snap code and not the dApp. Therefore, the Snap is soliciting permissions that are unnecessary, stemming from a misconception that it would be relevant for their test dApp as well.

Scenario #3: Unnecessary use of low-level permissions

In this scenario, a Snap requests access to low-level key material to compute the users Ethereum address, instead of asking MetaMask directly for the address.