Our susceptibility to a BadgerDAO-style hack

BadgerDAO has just had a front-end exploit for around $100 million.

I’m curious what our susceptibility to such an attack is. From what I’ve been able to gather, it was an XSS attack. The attacker used a compromised Cloudfare APi key to inject a script on the front-end that messes with the web3 API (talking with MetaMask or other wallets) and was able to ask for an approval to their own address. Looks like many people were fooled and approved the transaction.

But, at least these people were presented with a prompt asking if they wanted to approve the transaction. On the IC, no such prompt would be given. If the front-end we’re hacked, and the user were already logged in with Internet Identity or any identity using @dfinity/agent, it would be game over.

An XSS attack would have full power to act as the logged-in user. This is because the private key is stored in local storage, completely accessible to JavaScript running within that domain. I know this is very convenient, but it is also quite risky.

Are we okay with this security trade-off? I expect not many are aware of it.

Ethereum front-end app private keys are generally never stored in local storage, they’re stored separately from the domain of the web application. This adds an extra layer of protection against an XSS attack.

We don’t currently have that on the IC. Well, maybe Plug does this, since they are a browser extension. I’m not sure.

9 Likes

Sources( to reduce cross posts)

This topic is talking about local storage :

4 Likes

These are very good points, thank you. I like that they are only session keys. I hope we can somehow scope what the session keys do. For example, something like Stoic Wallet, when you log in with their identity solution I believe that session key has full access to the wallet. Perhaps this is an application-specific issue.

4 Likes