search

chainapsis / keplr-wallet

The most powerful wallet for the Cosmos ecosystem and the Interchain
https://www.keplr.app
Other
760 stars 453 forks source link

Manage Connections Potential Security Issue with IPFS Hosted Dapps #136

Open maxkoda-cpu opened 3 years ago

maxkoda-cpu commented 3 years ago

Our team just released a decentralized web application that we maintain on IPFS. It's a Dapp for the Secret Network and enables the use of the Keplr wallet extension. The Dapp is designed to run locally in the user's browser and it doesn't connect to any centralized endpoints (servers). Users typically obtain the Dapp via an IPFS public gateway.

When a user places the IPFS gateway link in the browser url, the dapp loads and starts to execute. When the user accesses the Keplr wallet extension, Keplr asks the user to approve wallet access for the IPFS gateway domain (for example, if the IPFS gateway is https://ipfs.io/ipfs/......, Keplr asks the user to approve wallet access for the ipfs.io domain. If the user accepts, this is a potential security risk!

We expect more and more Dapps to be distributed to users via IPFS in the future so we would like to see the Keplr wallet extension ask the user to approve the IPFS gateway domain + the IPFS hash of the Dapp being downloaded.

For example, our Dapp can be accessed by users with the following url: https://ipfs.io/ipfs/QmNRrLDhKGZCSXAZcPU1cBTaLouhWnTi5kfWUzJB4nJbzA

We would like Keplr to provide access to the full url (assuring that authorization is for our Dapp only, NOT anything residing on the https://ipfs.io domain). Is that a possible fix?

In the meantime, we have developed a solution that will allow our users to run our Dapp from localhost with a provided executable that we will open source. However, that's an extra step for the user.

emkman commented 2 years ago

This issue is mitigated by using an IPFS gateway that supports Origin Isolation. See: https://docs.ipfs.io/how-to/address-ipfs-on-web/#http-gateways https://ipfs.github.io/public-gateway-checker/

By addressing the URL with the CID as the subdomain of a supported gateway, users can limit the scope of their authorization in Keplr and not need to remove it after each use.

Though not all gateways support this, this would be more inline with standard security practices of the web and remove the need for a custom feature from Keplr.

woodydeck commented 2 years ago

Though not all gateways support this, this would be more inline with standard security practices of the web and remove the need for a custom feature from Keplr.

Isn't the standard security practice of the web to track you as much as possible since OS' funnel users into a few browsers?

I don't see it as a custom feature for Keplr as much as a required feature. In the MetaMask project, such dismissive responses to key security problems lead to me abandoning Ethereum for most things. People are stupid, including myself. All of the exploits of MetaMasks so far were reported well in advance of the attack, at least to my knowledge.

I'm working on improving the UX of the Monero bridge for my own project, and to see such opinions is disheartening. The Secret Bridge is a mess now, not user friendly, and it need all of us to be on the same page of security if laymen will ever use it. I would rather be broke and living in a favela than see this issue left open.

The fact there is no external commentary is even worse than disagreeing with an opinion. This bridge is a major deal, as are all bridges through privacy chains. The war against collectivist tyranny cannot be won without open supply lines free of mines.

Lucienest commented 1 year ago

What's the update? It's a major privacy risk as someone could probably be using many dapps.