Injection flaws are very common in the web application space, and they carry over to web APIs. Structured Query Language (SQL) injection is one of the most well known, but there are other injection varieties that can impact a range of interpreters and parsers beyond just SQL including, Lightweight Directory Access Protocol (LDAP), NoSQL, operating system (OS) commands, Extensible Markup Language (XML), and Object-Relational Mapping (ORM).
Attackers exploit these injection vulnerabilities by sending malicious data to an API that is in turn processed by an interpreter or parsed by the application server and passed to some integrated service, such as a database management system (DBMS) or a database-as-a-service (DBaaS) in the case of SQL injection (SQLi). The interpreter or parser is essentially tricked into executing the unintended commands since they either lack the filtering directly or expect it to be filtered by other server-side code.
Injection can lead to a wide range of impacts including information disclosure, data loss, denial of service (DoS), or complete host takeover. In many cases, successful injection attacks expose large sets of unauthorized sensitive data. Attackers may also be able to create new functionality, perform remote code execution, or bypass authentication and authorization mechanisms altogether.
In the example above the attacker appends the userId and sends additional syntax which will be parsed by the SQL query interpreter. This could cause the database to return all rows in the table as opposed to just the row that matches the user’s ID. That is because the SQL interpreter will evaluate both portions of the submitted SQL query. The application logic was built with the expectation that the user will provide their legitimate userId, which is then passed to the database service for a lookup in the backend database table or view defined in the server-side code. Normally, the SQL database engine will look for a row with the identifier that matches that of the userId provided by the client.
In this case, the attacker provided two components of a query through the front end web API, terminating the first part of the query with the use of a “ ‘ “ character. One query value is a userId, which need not even be valid. They also provided a query value that will result in a comparison of two numerical values. The value of 1 is of course equal to 1, which the SQL engine will evaluate as TRUE. Since the complete query string contains the OR operator, either component of the query that evaluates as TRUE will return TRUE for the final executed query. As a result, all table rows will match this SQL query string. The database service will return all rows in the table, and the data will be passed through the web API back to the attacker.
Protecting from injection attacks is common functionality for WAFs and some API gateways since these tools can use signatures to pattern match and identify known injection types. The signatures that these tools use, however, need to be kept up to date in order to protect against the latest injection attacks. If these tools lack the latest signature updates they will miss new attack types. Unfortunately, signatures are often built for off the shelf web and application software packages including open-source projects like Drupal and Wordpress. Software vendors and open source web content management system (CMS) project owners will call out pitfalls of WAF signatures for covering the range of custom development or plugins in their respective ecosystems. Web CMS also serve as development platforms. Custom code that development teams build within each respective ecosystem can look wildly different than what a WAF’s out of the box signatures are built for.
This is typically where WAF tuning discussions begin, or end, depending on your perspective. It can be difficult for many security teams to keep up with the rate of change of web pages, mobile apps and web APIs. The internet is also riddled with WAF evasion techniques that help attackers avoid WAF pattern matching mechanisms, commonly regex or libinjection. The situation gets worse for API gateways, which don’t receive signature updates regularly if at all. API gateways often employ basic threat protection or message filters that look for known malicious characters in requests and responses, such as “ = “ or “ ‘ “ in the case of SQLi. This type of approach is often too basic for organizations since it catches only basic injection attacks and may break other system integrations.
Another consideration is that WAFs focus on all web traffic, of which API traffic is only a subset and tangential focus. This may result in WAFs only being deployed with a positive security model to enforce traffic against an API schema or specific HTTP traffic patterns. Rulesets such as injection protections may also not be applied to API traffic.
An API security solution must be able to identify attackers probing APIs with potentially malicious data through all vectors. Injection flaws can be exploited in many parts of a request, including headers, cookies, URL query parameters, and message body variables depending how other backend application components and systems are architected. Detecting injection flaws successfully and early requires that the solution analyze all API traffic and establish a baseline of typical API behavior. From the baseline, the solution can identify anomalous and potentially malicious data in an API request such as what is seen in injection attacks. This can be done without the need for signatures or pattern matching, which eliminates the need to maintain configurations and signatures while ensuring that even injection attempts using the latest methods are identified and stopped.
Like many other API breaches, the Optus security incident highlights the importance of dedicated API security.
Salt Security's Roey Eliyahu and TAG Cyber's Ed Amoroso sat down together for a joint webinar on API security and zero trust. Check out the takeaways.