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!
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.
Your fingers glide across the keyboard, producing some sub-par code. It's not your best work but it works, and those corn chips are calling you. "That should do the trick", you mumble to yourself. Git add, git commit, git push, git out of here! You turn your phone off for the weekend and go hiking with friends.
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 PHP's
eval() function. The eval function takes a line of PHP code and evaluates it.
We escaped out of the initial string by adding a
"); at the start of our payload.
Any text after the initial
"); is interpreted as server-side PHP code, so we tested the code execution by using the
strtoupper(" at the end of the injection simply ensures that the rest of the line does not cause errors due to the trailing code after the injection.
Finally, we URL encoded the payload to ensure that the server receives all characters correctly.
A code injection illustration which shows a hacker sending a malicious code to an api
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.
University researchers at the University of Washinton were able to generate synthetic DNA strands containing malicious computer code to perform a code injection attack on some open source bioinformatics software!
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.
In PHP, avoid the use of dangerous functions such as
shell_exec(); especially when dealing with user input.
For example, instead of the vulnerable example from the interactive example above, which looks like this:
eval('echo "Hi there, " . strtoupper("'.$name.'");');
We could remove the
eval() function, and simplify our code like this:
echo "Hi there, " . htmlspecialchars(strtoupper($name));
Note that this example will also fix another flaw in the same line of code, XSS. Admittedly this is quite a simple example, but the point is that the vulnerability arises because dynamic data is being passed into the
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.
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.