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.
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.
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.
If the BadgerDao was hosted on the IC - the attacker would need to get access to the controller of that given canister and deploy update through consensus. Furthermore, if the canister was controlled by the DAO then any update to the frontend would need to be voted upon, which would make the attack impossible.
I think this is the foundation of IC that it is well protected against tampering with data on the chain, in case of BadgerDao - injecting code to the frontend.