Re: parity wallet, solidity methods are like HTTP endpoints. Using call or delegatecall from the default method is the new SQL injection.
It’s about time for the current generation of EVM languages to be retired, and the experiment of modeling external entry points to one’s smart contract as method calls to be declared a failure.
There’s a fundamental difference between external entry and the modelling of internal control flow in smart contract code that was happily and accidentally imposed on the web backend from the beginning. Since the dawn of the web, our code received a path, a set of headers and a body and we interpreted these in our code. When used with MVC frameworks, the entry points generally need to be called out in a document that specifies the server interface or by somewhat intrusive decorations.
Ethereum uses a conceptually similar mechanism to a network protocol in the abstract to make requests on a smart contract, but the ethereum ABI document goes a long way to leading everyone down the blind conceptual alley of treating smart contract calls like exported library functions in a program. While this might make it easy to just up and call a method on a foreign contract, hiding the distinction to a small degree between local and foreign code, I’m suggesting that treating contract interfaces in this way has always been the wrong metaphor and that’s never been more clear than it is now after the $300m parity wallet snafu.
It’s not a panacea, and somebody could obviously make the wrong decisions again. It’s not like there’s a shortage of insecure web apps after all, but having to specify the formal shape of an HTTP service by doing more than decorating a method with ‘public’ or ‘external’ gives the programmer a moment to pause and ask:
- Why am I putting this in the export list?
- What authentication middleware does it need?
- Does it make dangerous use of the external data?
I’m calling on the next generation of EVM languages to make the contract’s external interface explicit (although it’s invisible there’s a request decoder in your smart contract already), and different from the underlying language’s method call interface. We programmers are used to thinking about the world of code we can reach or be reached by as trusted and the world of wires and bits outside as untrusted. Everyone who ever wrote web services for long at some point in their lives has looked at a stack trace from an errored web call and said “oh i wasn’t expecting them to do that”. Let’s leverage the same shared unconscious in smart contracts.