My understanding is that the typical architecture for an Ethereum app is to have a smart contract acting as a backend to a centralized, stateless front end which runs on a single server.

Doesn't this pose a rather glaring security risk? If the front end app is hijacked, all of the users' actions can be misdirected to whatever the attacker wants (ie, instead of sending ether to a useful smart contract, it gets sent to the attacker's wallet).

Is there any way to host a front end app in a decentralised way?


This does indeed present a glaring security risk. In theory the user previews their transaction in MetaMask etc before sending, so they don't have to trust the dapp, but in practice the data you preview is a cryptic contract address and an inscrutable lump of hexadecimal data, and the context for that data - eg which kitty has which ID - comes from the dapp, so a rogue front-end could easily trick users into sending different transactions to the ones they intended.

The problem is probably solvable by serving content-addressed data off IPFS or Swarm served by a browser extension, and using a naming contract that enforces a deployment process - eg put up code for review before deploying - to control what code can be shown to the user for a given application name. However, these systems are difficult to design, and there is not yet a practical solution that can be easily deployed by dapp developers.

| improve this answer | |
  • Kind of strange that in all of the "how to's" I've read for bootstrapping a basic ethereum dapp, this concern is never mentioned. – jazzhole Feb 27 '18 at 23:36
  • I think my plan will be to upload to IPFS without any peer review, and just keep things really simple. Enforced deployment process is an interesting idea. – jazzhole Feb 27 '18 at 23:37
  • Well, it's not that nobody's worrying about it - there's a lot of work going on to make the situation better, from a few different angles, but it's a complex problem. – Edmund Edgar Feb 27 '18 at 23:52

Typically the purpose of a front-end for an Ethereum DApp is to provide a 'pretty' method of calling functions that are on the uploaded smart contract. Of Course, the hacker could change the address of the smart contract that the user interacts with (but the user is always able to see where their transactions are going). You can host a decentralized front-end with IPFS https://ipfs.io

The great thing about using a decentralized backend and using tools like EtherScan is that we are always able to see where our Ether is going and to who with relative simplicity.

If the frontend did happen to be high jacked and the hacker did change the contract address, the user would be able to see that their transactions are not going to the address that it should be (think of it as you know your friends street address, someone has stolen their phone and messages you to come to a different address with the intention of robbing you, you'll be wary of going to that address as you've never gone there before and there's no reason given as to why). You'd also be able to view the number of transactions that the contract has had on it (only useful if it's recently been high jacked). I think this is a somewhat minor issue and can be solved by using IPFS (It can be slow however).

To give an overview of what the hacker would have to do to get Ether maliciously from users, they would have too;

  1. Create and publish a new smart contract that funneled funds to their personal wallet
  2. Create a payable function in that smart contract
  3. Link that payable function to the front-end. The function would also have to have a similar gas price as not to arouse suspicions from users
  4. Change the ABI reference in the front-end
  5. Hope no one noticed!
| improve this answer | |

Yes that is correct, which is why you can host your dapps on IPFS+IPNS (after building with something like webpack).

The same logic is true for oracles, they are centralized points of failure.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.