Dr. Katie Paxton-Fear
Lecturer in Cyber Security, Speaker & Ethical Hacker, Manchester, England

Injection flaws, such as SQL, NoSQL, Command Injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

– OWASP API Security Top 10 2019 Report

What are injections?

Injection consists of sending an API malicious commands through a user input field, whether a text input, file upload, or other means. This attack vector allows malicious actors to send code or other executable commands to the API’s interpreter, which can be used to bypass security, change permissions, access information, damage, or disable the API. Common injections include cross-site scripting (XSS), SQL injections, and template injections.


How do injections impact vulnerable APIs?

XSS refers to Cross-Site Scripting. This type of attack involves injecting a malicious script into a text field or other input field on a website, which typically contains code that is executed for another website user. These succeed commonly where there is no sanitation of user input data. Potential damage includes obtaining session data such as cookies that can then be used as part of another attack involving a broken object-level authorization, for instance.

Websites (and thus APIs) often use databases. These can contain a variety of information, including but not limited to real names, e-mail addresses, payment information, and other personally identifiable information. SQL injections are another type of attack that focuses on accessing, manipulating, or destroying the databases behind APIs. Doing so can either provide information from a company’s customer base in case of access and temporarily affect their ability to do business or damage their reputation in case of database destruction.

As far as an injection is concerned, a vulnerable API does not sanitize the data before sending it to the interpreter. As a result, it can send the uploaded data directly to API components that can carry out instructions. This data can include OS commands, but also SQL/NoSQL/LDAP queries, and XML parsers. As mentioned above, if the injected code is executed, it may allow the person making the injection to access, modify or delete data that is supposed to be protected, or take down the target machines.

How can an API defend itself against injections?

The OWASP report strongly suggests that the API validates and cleans the data, relying on a “single, trustworthy, and actively maintained library”. The workflow thus involves a user submitting an input, whether through a text field or as a file, and the API “using sufficient filters to only allow valid values for each input parameter.” Syntax is not adapted for the target interpreter should be discarded entirely. While these controls are often built into languages and frameworks by default, it is important to ensure these components are kept up to date and are actually in use.

Injection has been a long-standing security issue in web security for several years, however, as APIs often rely on client-side filtering, they are particularly vulnerable to injection style issues.