Submit support requests and browse self-service resources.
Olaf van Gorp
Code injection is one of the most critical security vulnerabilities. And preventing malicious code injection is a top priority — especially when it comes to your APIs.
Malicious code injection occurs when an attacker exploits an input validation flaw in software to inject malicious code. This injected code is then interpreted by the application and changes the way the program is executed.
Malicious code injection is the top OWASP API security vulnerability. And ranks high among common vulnerabilities and exposures that modern enterprises face. It also currently ranks 6th in the Top 25 Common Weakness Enumeration of risks and common misconfigurations in distributed computing systems. SQL injection is still cited as the most used method by outsiders to cause a data breach.
Expert organizations like MITRE SANS & NIST provide specific recommendations on how to mitigate this risk using mediation techniques such as the use of an API gateway. In this blog, we share some of the mitigations that you need to know.
According to MITRE, there are four ways to mitigate malicious code injection. Some are more effective than others.
The first mitigation is moderately effective. The client application, API gateway, application server, and SQL server all should perform an appropriate level of “well-formed input validation” prior to processing the request.
This mitigation is also a programming best practice to prevent null pointer errors for required parameters. And it ensures that a field expecting a 5-digit integer is not instead being used to send an escape character with a string of SQL injection(s).
The second mitigation is clearly more effective. That's because SQL server itself ultimately has the responsibility to ensure that it only accepts requests from a trusted client via only the data network interface cards. This would be, for example, an X.509 certificate of each uniquely keyed API gateway — as opposed to a test request from a system administrator using the admin network interface and the X.509 certificate of the ‘DevSecOps’ user account.
This provides good coverage with respect to variations of the weakness.
The third suggested action, according to MITRE SANS, is to “lock down your environment”. This only minimizes the impact when this technique is used with a rating of “Defense in Depth” (DiD).
In a cloud computing environment, this is kind of moot, especially when considering that the infrastructure is usually completely shared. Even the use of dedicated infrastructure VPCs is limited these days given the temptation of quick iterative development collaboration environments and low operational expenses.
The fourth suggested mitigation is limited in effectiveness. It simply assumes that external components can be subverted — and that one’s code can be read by anyone. This pretty much means that security by obscurity in so-called “secret code” has never and will never be effective.
In addition, an effective practice to complement MITRE's suggested actions is to use a SAST tool to identify software secure vulnerabilities and enforce secure coding standards—such as CERT, CWE, and OWASP.
Here's how Akana can help you prevent malicious code injection.
Akana recommends a policy-first approach when mitigating API security concerns. You don't have to require API developers to create code to deal with a multitude of potential API vulnerabilities. Instead, you can ensure security by configuring policy instances from a library of available policy types and applying these to the APIs.
This approach to preventing code injection has some great advantages:
Akana provides a “malicious pattern detection” policy type that can be configured to avoid SQL injection.
Applying this policy on an API ensures that no SQL input will be accepted wherever it is inserted in the request. Payload and input parameters are all subject to content validation. Akana allows for policies to be created to handle both JSON and SOAP-XML input messages.
In a well-architected API security approach, message content validation is preceded by client authentication and authorization policies. This ensures that the client is a valid entity that should be allowed access to the API resource.
An additional safety measure for code injection, aimed at safeguarding the integrity of the message (and possibly even its confidentiality), could be put in place. For example, you could require the message to be signed, preferably using a PKI-based approach. Though authenticity of the client would now have been validated, the intent of the user on whose behalf the client is making the request cannot simply be assumed to be benign.
Having a malicious pattern detection policy in place together with the other measures ensures that improper content will not be allowed to pass. This safeguards your systems from having to deal with malicious requests.
Security is paramount in the enterprise. And the Akana API platform makes it easy to ensure powerful security — and automate the process.
Preventing code injection was a top priority for a large bank.
By choosing Akana as their API platform, the large bank was able to:
Learn more about how the large bank used Akana to open new channels, keep up with market trends, and comply with requirements. Read the case study >>
See for yourself how Akana can help you strengthen security AND accelerate time-to-market.
▶️ WATCH A DEMO
Explore additional resources:
Technical Sales, Akana
Olaf has over 20 years’ experience with software development and architecture, helping organizations such as Compuware and Capgemini solve enterprise-level integration and governance issues. Olaf has supported the technical sales for Akana API management since 2014, diving deep into security challenges as well as issues specific to financial services, such as PSD2 and Open Banking.