Given their role, APIs interact with several other (software) components such as filesystem, databases, LDAP, or other internal and external APIs. Not all these components are capable of validating and sanitizing the input they receive. When APIs neglect this responsibility, properly validate and sanitize untrusted input data before passing it to another component, they end up vulnerable to Injection attacks.
What is the issue?
Data coming from untrustworthy sources, such as users or external systems such as third-party APIs, is not properly validated, filtered, or sanitized. Usually, this means that such data is directly used or concatenated to SQL/NoSQL/LDAP queries, OS commands, XML documents, and Object Relational Mapping (ORM)/Object Document Mapper (ODM).
How does it look like?
One OWASP API Security Top 10 2019 Injection attack scenario is based on a real command injection vulnerability on a parental control device. Usually, the computational capabilities of such devices are very limited and functionalities are provided by the firmware, meaning that operations happen at a low level. To restore factory configurations for a specific application, one should issue the following request:
Chances are that, to restore the factory settings, some of the user-provided data is passed to a system call, for example, the appid. If appid is not properly validated nor sanitized, and instead directly concatenated to an operating system command, attackers may be able to execute other existing programs on the device.
Most of these devices run a Unix operating system therefore we need to inject something the underlying system understands, for example, running a program on a sub-shell:
Based on the original research, issuing a request like the one below, researchers were able to shut down any reachable device:
Why? Because the value of the “appid” request parameter was directly being used to compute a command line from a template string, as shown below:
Without proper validation, directly using the “appid” value with the command line template string will result in the following command:
Before running the “restore_backup.sh” script, the operating system will execute the “/etc/pod/power_down.sh” command (“appid” parameter value) in a sub-shell, shutting down the device.
Where have we seen this issue lately?
Michael Stepankin found two parameter injection issues on Apache Solr API. Nagios XI, a popular system and network monitoring solution, was vulnerable to several injection issues such as SQL Injection (SQLi) (CVE-2019-9204) and Command Injection (CVE-2018-15709).
Preventing injection issues requires keeping data separate from commands and queries. Most common development frameworks provide well-tested and maintained validation libraries but, it is up to the developers to use them properly. Failing to do so is a common cause of injection vulnerabilities.
To properly mitigate and address injection issues, it is important to know how the data flows from one component to another and how data is handled by the target component. Usually, static analysis tools do a decent job finding injection vulnerabilities, but adopting code review as a standard practice is almost mandatory.