Submit support requests and browse self-service resources.
Olaf van Gorp
Protecting against a malicious code injection with a cloudy DMZ of Akana API gateways.
Although this type of cloud computing API risk still ranks first in the OWASP Top 10 and 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.
To prevent data loss, the yearly Data Breach Investigations Report and the “State of the Internet” SOTI Report both acknowledge this common vulnerability with systems using relational databases as one of the top risks to mitigate. 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.
According to MITRE, there are four ways to mitigate this risk, some more effective than others. The first mitigation offers a “moderate” level of effectiveness and the suggestion is to “establish and maintain control over all of your inputs.”
The second mitigation offers a stronger level of protection with an effectiveness described as “good coverage with respect to variations of the weakness” and the suggestion is to “establish and maintain control over all of your outputs.”
Before looking at the other two mitigations, let’s pause here and consider why the second mitigation is stronger than the first. Furthermore, let’s look at how to leverage the Akana API Gateway cluster (on premises or in the cloud) to implement both mitigations with a single product implementation and slight architectural shift in the full lifecycle API management of the SDLC process.
The first mitigation is essentially saying that 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 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 because the 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.
The third suggested action, according to MITRE SANS, is to “lock down your environment” and is said to only minimize 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 got an effectiveness rating of “limited” and is to simply assume 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.
Akana recommends a policy-first approach when mitigating API security concerns. Rather than requiring API developers to create code to deal with a multitude of potential API vulnerabilities, security can be ensured 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. In addition to the benefits listed above, 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 will typically have been preceded by client authentication and authorization policies, ensuring 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 by requiring 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, whether or not intentional included in the message, will not be allowed to pass, thus safeguarding your systems from having to deal with malicious requests.
Learn how the Akana platform enables API security best practices.
Visit Security Hub
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.