This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Injection Prevention Cheat Sheet"

From OWASP
Jump to: navigation, search
(Rule #1 (Use a safe API):)
(Rule #0 (Perform proper input validation):)
Line 49: Line 49:
 
= Injection Prevention Rules  =
 
= Injection Prevention Rules  =
  
=== Rule #0 (Perform proper input validation): ===
+
=== Rule #1 (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.
 
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.

Revision as of 13:44, 6 April 2010

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.

Application accessibility is a very important factor in protection and prevention of injection flaws. Only the minority of all applications within a company/enterprise are developed in house, where as most applications are from external sources. Open source applications give at least the opportunity to fix problems, but closed source applications need a different approach to injection flaws.

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.

Depending on the accessibility different actions must be taken in order to fix them. It is always the best way to fix the problem in source code itself, or even redesign some parts of the applications. But if the source code is not available or it is simply uneconomical to fix legacy software only virtual patching makes sense.

Application Types

Three classes of applications can usually be seen within a company. Those 3 types are needed to identify the actions which need to take place in order to prevent/fix injection flaws.

A1: New Application

A new web application in the design phase, or in early stage development.

A2: Productive Open Source Application

An already productive application (with MVC architecture), which can be easily adapted.

A3: Productive Closed Source Application

A productive application which cannot or only with difficulty be modified.

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. For more information see the SQL Injection Prevention Cheat Sheet.

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 #1 (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.

Rule #2 (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.

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.

Injection Prevention Matrix

App
Solution
est. Work
A1 Can be avoided by using an OR-Mapper (e.g. Hibernate) or consistent parametrization of all input data (e.g. stored procedures or ideally: prepared statements). Other injection flaws (e.g. with XML) can only be avoided with dedicated output coding, where necessary 1
A2 Rewrite parts of the application, to fix the problem or embed a library like the OWASP ESAPI to introduce black and white list based input validation 3
A3 Deploy a web application firewall to introduce virtual patching (black, white and pro active security measures) 2

Depending on the application and the proposed solution a specific amount work is required.

  • 1 little work required
  • 2 moderate amount of work required
  • 3 considerable amount of work required