Injection

OWASP defines Injection flaws as follows:

A1:2017 – Injection

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

Injection is a broad concept that covers many different security risks.

What’s common to all of them is that “interpreters” running in the app’s background can be intentionally cheated to run code that can be exploited by an attacker.

Depending on the underlying interpreter, injection flaws can occur on SQL-engines, LDAP engines, OS command-interpreters, XML interpreters, etc. 

 

Tainted Data Flow

A common injection root cause is to send untrusted (potentially tainted) data to an interpreter as part of a command or query.

Source locations are those places in the code from where data comes in, that can be potentially controlled by the user (or the environment) and must consequently be presumably considered as tainted (as they may be used to build injection attacks).

Sink locations are those places where consumed data must be untainted.

 

You app will contain an injection point (an injection vulnerability) wherever a data flow exists where any sink consumes input data which is not being properly neutralized. Kiuwan scans your source code to find any injection point:

 

For all possible sinks, prove that tainted data will never be used where untainted data is expected.

 

Injection Prevention Rules

As in any other security matter, there’s not a unique protection mechanism and the best approach is combining more than one.

To prevent Injection flaws we can consider the following complementary approaches:

  1. First line of defense consists on using the interpreter though a safe API (i.e an API that avoids the use of the interpreter entirely or provides a parameterized interface). 
    • Even so, be careful of APIs, such as stored procedures which are parameterized, but can still introduce injection under the hood.
  2. If you cannot use a safe API (or even using it), you should always perform an adequate input validation. 
    • By input validation, we mean accepting only what is known to be good (whitelist), rejecting what is known to be bad (backlist) and escaping special characters using the specific escape syntax for the interpreter.

This is a general approach to prevent injection flaws. But, depending on the interpreter, there can be further prevention possibilities.

When Kiuwan scans your source code, all the vulnerabilities of the same type are grouped under a Kiuwan rule, indicating how many files are “affected” (and where), how many vulnerabilities were found, and providing specific remediation clues based on the specifics of the programming language or interpreter being used.

What follows is a description of the main types of injection attacks, providing references to further detailed documentation and the detection coverage provided by Kiuwan.

 

Injection types

Kiuwan provides out-of-the-box rules to detect Injection points in the following programming languages:

  • Abap, ASP.NET, C/C++, C#, Cobol, Java, JavaScript, JSP, Objective-C, Oracle Forms, PHP, PL/SQL, Python, RPG IV, Swift and Transact-SQL

 

This list is continuously growing, if you miss any programming language, please contact Kiuwan Support.

It follows an explanation of the most common injection types (referred by their CWE ID#). You can visit https://cwe.mitre.org/ for further information on every injection type.

 

Nevertheless, although we will concentrate on this subset, there are many other injection attacks also covered by Kiuwan.

Below you can find a list of injection attacks not covered in this paper but controlled by Kiuwan.

 

Index of Injection types