Code injection attacks, which are sometimes referred to as remote code execution attacks, can be a serious threat to an organization’s security. Interestingly, however, the phrase “code injection attack” does not refer to a specific attack method. Rather, it is a generic term used to describe an exploit in which attackers exploit poorly written code in a way that allows them to execute their own code. The more you know about this cyber attack method, the better prepared you will be to stave it off in the first place.
Code injection attacks are a cyber attack method commonly directed against programming languages such as PHP or Python. However, the underlying platform is somewhat irrelevant since past attacks have been directed against a wide variety of platforms. Code injection attacks have targeted everything from SQL Server databases to Windows PowerShell.
The exact mechanics of a code injection attack vary widely based on the platform that is being attacked, but code injection attacks typically have one thing in common: They exploit unvalidated input.
Here's a really simple example.
Almost all popular websites allow user-created content. A site might, for example, allow its users to review a product or comment on a video. Site users typically enter their comments into a text box and then click a submit button. Upon doing so, their comment is added to the page.
Early on, Website owners discovered that this seemingly simple process could be exploited. Rather than entering plain text into a comment box, those who had bad intent would sometimes enter HTML code. In many cases, sites would actually evaluate the code, rather than simply displaying the code as plain text. Spammers sometimes used this technique to plaster ads (complete with pictures and large fonts) all over Internet comment boards. Those who had malicious intent would sometimes embed redirects into their code, in hopes of infecting site visitors with malware.
There are two main things that are necessary for a modern-day code injection attack to succeed.
First, there has to be some opportunity for an attacker to enter malicious code. Remember, though, the phrase “code injection attack” is a generic term. As such, there are conceivably any number of ways that an attacker could enter malicious code.
Code injection attacks commonly target text entry fields within applications. An attacker might, for instance, try to enter commands into a field that asks for a piece of information such as a user’s name or address. Comment fields are also a favorite potential target.
A browser’s address bar is another popular target. Many websites append page-specific parameters to the end of a URL. Since these parameters are in plain view, an attacker may try to exploit them as a means for gaining access to the site’s backend resources.
The second thing that an attacker needs to make a code injection attack work is a means of executing the instructions that they enter into the target website, script or application. There really isn’t much that attackers can do to force their code to be executed, so they generally rely on persistence and a bit of luck. Attackers might, for instance, enter the same command into dozens of different form fields, in hopes that one of those fields will have been constructed in a way that causes the instruction to be executed.
There are three main things that application developers must do to keep their applications from being exploited by a code injection attack. First, input validation is an absolute must. Put rules in place that will limit what can be entered into a field. If a field is asking a user to enter his or her name, for example, then you might limit the number of characters that can be entered and prohibit the use of numbers and special symbols. These steps will go a long way toward preventing code injection attacks.
Second, avoid including any instructions that could cause user input to be executed. In the case of a PowerShell script, for instance, you might want to avoid using the Invoke-Expression cmdlet. In the case of PHP code, you should avoid using eval().
And, lastly, thoroughly test your applications (including any subsequent patches). Try entering benign commands into text fields to ensure that the application is properly handling the input.