Mini App Entitlements

[CassOnMars]

Summary

Mini apps in leading clients (Farcaster and TBA) have a few layers of defense in preventing malicious wallet activity, transaction simulation being the front-line, plus proprietary strategies left unstated for greater defense in depth. The attack today, with the NPM author Qix being compromised, was a very short lived (and effectively unsuccessful) attack due to two very important events: the compromise was detected very quickly, and most project maintainers do not upgrade packages one to two hours after the updated package is released. While some more security-aligned teams engage in practices involving static versioning, local cache proxying of packages, and static/dynamic code analysis of dependencies, most do not, and the real insight to be drawn from this is that had the attacker not been quickly caught, the damage of this event would have been far more vast. The only clear conclusion to come to is that luck was the strongest factor in limiting damage, this time.

Transaction simulation is one of the most common techniques used by wallets to avoid malicious transactions from occurring: either by knowingly detecting fingerprints of a malicious transaction, providing useful metadata to the wallet owner of the consequence of signing, or when the call is too complex to simulate, warning the user at a minimum that they are signing at their own risk. Additionally, the need for third party simulation services adds one more link in the dependency chain itself – either in ways that can de-anonymize users, or serve as another target for an attacker to hit. Drilling into the root of the problem, the grand majority of malicious signature requests can be solved with a more proactive approach, which will be the focus of this proposal: Entitlements.

What are entitlements?

Entitlements are a common feature in mobile app development, cloud application deployments, and increasingly in desktop application development as well. The core intent is to limit the blast radius following the Principle of Least Privilege, such that if a compromise occurs, it is limited to the requested entitlements only. An example would be limiting a cloud photo editing application to only have access to photos the user willingly grants, instead of access to all photos on a phone. After many years of attacks and leaks with consequences ranging from embarrassing to personally and financially devastating, Apple leans very pro-consumer in ensuring users are able to enforce their consent to full or partial disclosure of entitlement-driven resources. Structurally, entitlements tend to represent a type of taxonomic filter, e.g.:

domain -> namespace -> resource [-> category] -> action -> <conditional filter expression with or without wildcard>

This methodology tends to be JSON and/or URI structured, depending on degree of complexity, such as AWS' IAM policies:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "FirstStatement",
      "Effect": "Allow",
      "Action": ["iam:ChangePassword"],
      "Resource": "*"
    },
    {
      "Sid": "SecondStatement",
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "*"
    },
    {
      "Sid": "ThirdStatement",
      "Effect": "Allow",
      "Action": [
        "s3:List*",
        "s3:Get*"
      ],
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket-confidential-data",
        "arn:aws:s3:::amzn-s3-demo-bucket-confidential-data/*"
      ],
      "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
    }
  ]
}

This policy document structure is rather exhaustive, and arguably is not needed for mini apps. We propose a simpler format, such that in the future, if it need be expanded, it can easily and extensibly be done, but is minimally scoped now to solve the core issue.

Proposal: Add entitlements field to Mini App config schema

Presently, Mini Apps can declare what features they expect from the Mini App host with requiredCapabilities (and somewhat with requiredChains), but this is moreso a filtering feature for host compatibility, and does not tell the host what the user should be prompted to consent to provide. Adding a new field, entitlements: string[], would offer the ability for Mini Apps to declare exactly what should be required from users, their connected wallets, and at the same time, inversely let the mini app host to stop any requested action that is out of scope of declared entitlements.

{
        "name": "Example",
        "version": "1",
        "iconUrl": "https://example.com/icon.png",
        "homeUrl": "https://example.com",
        "imageUrl": "https://example.com/image.png",
        "buttonTitle": "Open",
        "splashImageUrl": "https://example.com/splash.png",
        "splashBackgroundColor": "#FFFFFF",
        "webhookUrl": "https://example.com/api/webhook/miniapp",
        "subtitle": "Example Mini App",
        "description": "Lorem Ipsum",
        "screenshotUrls": [
            "https://example.com/screenshot.png"
        ],
        "primaryCategory": "social",
        "tags": [
            "social",
        ],
        "heroImageUrl": "https://example.com/hero.png",
        "tagline": "Example Mini App",
        "ogTitle": "Example",
        "ogDescription": "Example Mini App",
        "entitlements": [
            "wallet:ethereum:signer:transfer:0xowneraddressofapplication",
            "wallet:ethereum:rpc:estimateGas:*",
            "wallet:ethereum:rpc:call:*",
            "wallet:ethereum:signer:signMessage:example.com wants you to sign in with your Ethereum account:\n0x[a-f0-9]+\n\n.*"
        ]
}

The entitlement structure is thus:

<domain>:<namespace>:<resource>:<action>:<filter>

Benefit: App compromise prevents stolen user funds

Broken down in this way, the ability for a compromised application to engage in malicious behaviors is effectively limited to transferring assets to the owner of the application, making two kinds of immutable requests from the connected RPC, and a SIWE request to the given application, leaving no room for a compromised UI to send funds to an attacker, no transaction simulation required.

Benefit: Transaction simulation is lessened in necessity

Transaction simulation APIs are a repository of wallet data and actions that may never even occur. For privacy sensitive users, it increases the potential of unintentional exposure – a user on the unintended wallet, seeing the transaction simulation being with the wrong address, could switch to their other wallet, which now effectively links the two possibly prior-to unrelated addresses. There are also costs associated with transaction simulation APIs, making it harder for open source clients to provide the same level of security – by applications declaring all they intend to request from the user, this can be checked within the mini app harness without needing to rely on simulation services.

Benefit: Users know exactly what to expect from an application

At this time, no EIP exists that actually allows applications to declare entitlements requested from a wallet – the closest is a feature to interrogate the wallet for supported functionality, but this doesn't actually prevent an application taking more actions than a user expected or wanted. Structured in the proposed way, this also supports more than EVM-centric wallets, giving a universal set of expectations users can consult and more easily provide informed consent towards.

[dazthecorgi]

Thanks for writing this up! It's a very important problem that should be addressed. I've added some questions/thoughts below.

Drilling into the root of the problem, the grand majority of malicious signature requests

Is the intention with entitlements to prevent malicious signature requests from both compromised and outright malicious mini apps or only from compromised mini apps?

The core intent is to limit the blast radius following the Principle of Least Privilege, such that if a compromise occurs, it is limited to the requested entitlements only. An example would be limiting a cloud photo editing application to only have access to photos the user willingly grants, instead of access to all photos on a phone. After many years of attacks and leaks with consequences ranging from embarrassing to personally and financially devastating, Apple leans very pro-consumer in ensuring users are able to enforce their consent to full or partial disclosure of entitlement-driven resources.

I think there is value in forcing developers to think about entitlements in itself, but devs don't tend to follow the principle of least privilege unless they're incentivized to (e.g. by app review) due to lack of time or awareness. Is there such an incentive in the mini app context?

Benefit: App compromise prevents stolen user funds

What would be the mechanism for changing entitlements? How is privilege escalation by a compromised mini app prevented?

Benefit: Users know exactly what to expect from an application

This is a tricky one and I think entitlements alone will not solve this. Only technically advanced users would understand entitlements and even they would fall into satisficing behavior (just click ok to get shit done) if they had to review too many permissions.

So entitlements should be combined with other techniques to achieve informed consent. These techniques include:

• reducing the number of permissions requests with trusted UIs
  • e.g. instead of the mini app requesting permission to make a transfer, it delegates to the host's transfer UI
• automatic grants if the action is easily reversible
  • e.g. a mini app that enhances a profile pic should be able to do it without a permission request, but the host should make sure the user can revert to the original pic easily
• delaying permission requests until the user is in a flow that facilitates optimizing behavior
  • the canonical example for this is requesting location permissions when a user requests a ride in the Uber app instead of requesting location permissions when installing
  • to support this, mini apps should be able to request permissions after they were installed
• isolation techniques to avoid asking for permissions altogether
  • e.g. create new signers/identities for untrusted mini apps