Code injection is a type of attack that allows an attacker to inject malicious code into an application through a user input field, which is then executed on the fly. Code injection vulnerabilities are rather rare, but when they do pop up, it is often a case where the developer has attempted to generate code dynamically. Preventing code injection attacks usually comes down to reconsidering the need to dynamically execute code, especially where user input is involved.
In this lesson, you will learn how code injection works and how to protect your applications against it. We will begin by exploiting a code injection vulnerability in a simple application. Then we will analyze the vulnerable code and explore some options for remediation and prevention.
Ready to learn? Buckle your seat belts, put on your hacker's hat, and let's get started!
The Godfather Of Vulnerabilities: Code injection has been around about as long as computers, but its prevalence is waning. In 2008, 5.66% of all vulnerabilities reported that year were classified as code injection, the highest year on record. By 2015, this had decreased to 0.77%. It is even more rare today, but if your server has one, it will be sleeping with the fishes.
Let's set the scene. You're a 9-5 developer working for BigCorp and it's 3.30pm on a Friday. The coffee is running hot but your eyes still feel heavy. One more hour and you'll be git pushing yourself all the way home for some corn chips and late-night Call of Duty.
All you need to do is make a string uppercase and greet the customer in onboarding. You've heard something about
eval() being bad, but right now you just want to get the job done. You take a deep breath and blow on your piping hot coffee. Let's do this.
Let's jump into the nitty-gritty details of how this code injection works:
As an attacker, we were able to determine that our input was being injected directly into a Node.js
We escaped out of the existing string by adding
"; at the start of our payload.
Any text after the initial
process.version variable using this payload:
// at the end of the line is simply to avoid syntax errors from trailing characters.
And now we will have a look at this example in more detail by going through the server-side code.
If a code injection vulnerability exists in an application, the security impact is that an attacker is able to execute arbitrary server-side code.
The ability to execute server-side code can result in a total loss of integrity, availability, and confidentiality within the application. An attacker may also abuse a code injection vulnerability to execute terminal commands on that server and pivot to adjacent systems.
Today, code injection is not a very common vulnerability. There is rarely a situation where it would make sense to inject user input into an eval() function. The use of eval() is typically an indication of bad software design, and there is usually a better alternative.
In general, the proliferation of server-side web frameworks and libraries over the last decade has also decreased the need to custom code many tasks, reducing the likelihood that vulnerabilities will be introduced, and increasing the ease of writing sound, secure code.
Having said this, occasionally code injections can still make their way into popular libraries. One pertinent example is in the LinkedIn DustJS templating engine in 2016. If you are interested, check out the full details of the vulnerability.
Despite the rarity of code injection vulnerabilities, they are included in common checks because of their critical severity.
Some hackers are born with it. Researchers were able to generate synthetic DNA strands containing malicious computer code to perform a code injection attack on some open source bioinformatics software!
setInterval() and the
Function constructor, especially when dealing with user input.
For example, instead of the vulnerable example from the interactive example above, which looks like this:
uppercaseName = eval('"' + name + '"' + '.toUpperCase()')
We could remove the
eval() function, and simplify our code like this:
uppercaseName = name.toUpperCase()
Admittedly this is quite a simple example, but the point is that the vulnerability arises because dynamic data is being passed into the
Perhaps the most straightforward of all prevention techniques is to reconsider the need to evaluate any dynamically generated server-side code. Usually, this dynamic code execution is the result of poor software design rather than necessity, so it's always best to consider other ways to achieve the task.
If the interpreter you are using allows, lock it down by limiting the functionality to the minimum amount required by your application in the server configuration. If you are using PHP, one method is to use the
disable_functions directive within the
php.ini file. This will instruct the PHP server to ignore any instances of the defined functions. Of course, this will also mean that those functions can not be used at all on that server.
Adding a static application security testing (SAST) tool to your devops pipeline as an additional line of defence is an excellent way to catch vulnerabilities before they make it to production. There are many, but Snyk Code our personal favorite, as it scans in real-time, provides actionable remediation advice, and is available from your favorite IDE.
That's where eslint-plugin-security-node comes in. In order to install it, run the following command:
npm install --save-dev eslint-plugin-security-node
Then add the following configuration to your
The plugin contains rules that will test your code for vulnerabilities when you run
npm test. It's important to note that linters like this will not catch everything. But they are a good sanity check, and the more layers of checks we have the less likely you are to introduce vulnerabilities.
To learn more about code injection, check out some other great content:
Have a look at the OWASP code injection page that goes over some other examples of code injection.
We all love cheatsheets, to check this one here, where you can read about other types of injection and how to prevent them.
If you loved the lesson, don't forget to check out our article about command injection.
You have taken your first step into learning what code injection is, how it works, what the impacts are, and how to protect your own applications. We hope that you will apply this knowledge to make your applications safer. We'd really appreciate it if you could take a minute to rate how valuable this lesson was for you and provide feedback to help us improve! Also, make sure to check out our lessons on other common vulnerabilities.
Are you sure that you don't have this vulnerability in your codebase?Quick Start - Start For Free