I recently came across a stern warning.
It was embedded in an interesting article, which lists a number of things that weren’t expected to be Turing complete, but are.
This is more than just an amusing list of Eleven Crazy Things You Didn’t Expect To Run Code; Engineers Hate Them. Instead, it holds an important lesson.
As engineers who build systems that communicate with the outside world, we need to be aware of such surprising emerging complexity: it can lead to shocking attack vectors.
It would be unwise to assume that a device which resides in the customer’s hands is trustworthy.
To a talented attacker, it would be easy to modify or reverse-engineer it to the point where it could be used against our infrastructure.
And I’m not just talking about DoS attacks, which, while unpleasant in many ways, are at least totally obvious.
I’m rather more worried about sneaky ways to attack the soft insides of our system: SQL (or other) injections – or running code in things you didn’t expect to be able to run code.
Remote execution: an attacker running arbitrary code on your backend – that’s bad enough. But running code on things you didn’t expect to be able to run code: that’s even worse.
And since this kind of thing is unexpected almost by definition, the best line of defense is: don’t even trust your backend.
Give it minimal permissions. Validate its data. Erect barriers between various parts of your infrastructure.
Don’t imagine that you can trust a system just because it’s not accessible to outsiders. BECAUSE IT IS. That’s the whole idea behind networked systems, isn’t it?
In short: use good engineering practice and common sense. Don’t get lazy, or you’ll pay for it. Either with all-nighters, or with your customers’ data, or with your entire business.
Do you have a question? A project proposal? Something special in mind? Contact me, and let’s talk about how I can make your team, your products, and your life better