Most web developers are familiar with SQL injection, an all-too-common web vulnerability. The problem typically arises from assembling SQL queries by concatenating strings, without considering they’re allowing whoever supplies the parameters (typically, a consumer of a web API) to write their own SQL code. But SQL isn’t the only place you can get code injected. SQL injection has a close cousin that’s not nearly as well-known, but it’s just as—if not more—deadly: command injection.
An Introduction to Command Injection
This vulnerability has been popping up quite a bit lately. It particularly crops up in smart devices running Linux, as developers figure out ways to run external programs inside their software. However, it’s not limited to the Internet of Things; it can appear anywhere.
I introduced this topic in a five-minute lightning talk at a lunch-and-learn held at our neighbor Nutshell’s offices. In this video, I tell you about the risky way most developers end up opening their code to command injection. I also discuss the most important thing you can do to defend against it.
Additional Defenses and Further Reading
Immediately after this talk, I had a really good follow-up discussion with a colleague. He reminded me of one more important thing worth mentioning. For a simple defense against not just all kinds of code injection attacks, but many other kinds of attacks as well, make sure that your software is sandboxed to give it exactly what rights it needs on the system—and no more. This simple configuration, stacked with use of the correct APIs to launch external processes, will help defend your application from this attack—and others.
For further reading on this topic and all kinds of other ways to defend your web application, OWASP is a great resource. I recommend reading their page on command injection in particular. It’s important that all software developers to know of attacks like these and write code that effectively defends against them.