Injection Prevention Cheat Sheet

= Introduction =

This article is focused on providing clear, simple, actionable guidance for preventing the entire category of Injection flaws in your applications. Injection attacks, especially SQL Injection, are unfortunately very common.

= Introduction =

Problem Description
Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. Injection flaws are easy to discover when examining code, but more difficult via testing. Scanners and fuzzers can help attackers find them.

Forms of Injection
There are several forms of injection targeting different technologies:

Query languages
The most famous form of injection is SQL Injection where an attacker can modify existing database queries. But also LDAP and XPath queries can be susceptible to injection attacks allowing for data retrieval or control bypass.

Scripting languages
All scripting languages used in web applications have a form of an eval call which receives code at runtime and executes it. If code is crafted using unvalidated user input code injection can occur which allows an attacker to subvert application logic and eventually to gain local access.

OS calls
Application developers sometimes implement operating system interactions using calls to system utilities to create and remove directories for example. Here unvalidated input can lead to arbitrary OS commands being executed.

Network Protocols
Web applications often communicate with network daemons (like SMTP, IMAP, FTP) where user input becomes part of the communication stream. Here it is possible to inject command sequences to abuse an established session.

= Injection Prevention Rules =

Rule #0 (Perform proper input validation):
Perform proper input validation. Positive or “whitelist” input validation with appropriate canonicalization is also recommended, but is not a complete defense as many applications require special characters in their input. OWASP’s ESAPI has an extensible library of white list input validation routines.

Rule #1 (Use a safe API):
The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood. If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter. OWASP’s ESAPI has some of these escaping routines.

Rule #3 (Contextually escape user data):
If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

Description of Injection Vulnerabilities

How to Avoid Injection Vulnerabilities

How to Test for Injection Vulnerabilities