1: Broken object level authorisation
4: Lack of resources & rate limiting
5: Broken function level Authorization
10: Insufficient logging & monitoring
The injection vulnerability is caused by not validating user input, where that input is later used verbatim without any protection mechanisms. The input, if used for example, as an update to a field in a relational database may contain text that terminates the SQL query and performs additional queries. If the input is not sanitised to remove potential SQL query string modifications then it will be executed as a successful statement.
Another example scenario is when user input is used to determine program level conditional branches. If the input is used directly then it may allow an attacker to control how the branching is determined.
Finally, and this example list is by no means complete, if user input is provided directly to the execution of shell commands then if not properly sanitised and validated the attacker can execute any command with the permission level of the service executing the command. If the server has other security vulnerabilities in dependent libraries then the attacker may also be able to elevate privileges.
To prevent injection, many languages, either built-in or through libraries, offer ways to sanitise user input. For example, in the case of relational database systems, many have stored procedure capabilities that separate the input variables from the query itself.
OWASP summary
| Threat agents/attack vectors | Security weakness | Impacts |
| API specific : Exploitability 3 | Prevalence 2 : Detectability 3 | Technical 3 : Business specific |
| Attackers will feed the API with malicious data through whatever injection vectors are available (e.g., direct input, parameters, integrated services, etc.), expecting it to be sent to an interpreter. | Injection flaws are very common and are often found in SQL, LDAP, or NoSQL queries, OS commands, XML parsers, and ORM. These flaws are easy to discover when reviewing the source code. Attackers can use scanners and fuzzers. | Injection can lead to information disclosure and data loss. It may also lead to DoS, or complete host takeover. |
Source: OWASP injection
APIM context
The APIM can ensure that input conforms to the schema and is well formed and valid input. Validation of the data itself can also be achieved through the use of body transformations and custom plugins.
Tyk approach
Validation of input can be achieved with several Tyk features:
- JSON schema validation to ensure the payload meets the defined schema, and rejects payloads that do not.
- Body transformation allows using string template syntax, which is a powerful tool for generating the desired output from the input.
- Custom pluginsfor more complex cases or logic not satisfied by the first 2, users can write custom plugins in a variety of languages, either directly or through gRPC calls, to implement their requirements.
Injection vulnerabilities are especially difficult because they are implementation specific. Various vendors, languages, libraries, utilities, and business logic can make a general turn-key solution difficult. A general good rule of thumb is to never trust user input and validate the input at all levels possible and before use.
