Injection Cheat Sheet - Revision history

Jmanico: redirect to the active CS on injection

2017-11-13T20:08:35Z

redirect to the active CS on injection

Jmanico at 20:14, 23 March 2011

2011-03-23T20:14:30Z

Jmanico: Blanked the page

2010-04-04T04:57:07Z

Blanked the page

AlexanderMeisel: First Version

2010-04-01T11:26:02Z

First Version

New page

= Introduction<br> =

== Problem Description ==

Injection vulnerabilities are a form of '''data becomes code''' issue. The transition from data to code often happens due to ''in-band'' control characters, which mark the beginning (and end) of a commando block. Injected data can be (if syntactically correct) interpreted by an interpreter performing various tasks on the given input. An "interpreter" here is anything that receives and executes commands. Injection attacks are usually server and web application centric attacks with perfectly valid application layer traffic and is thus hard to detect for classic network security components.

== 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 (''Golden Rule''): ===

• Perform proper input validation.

• Prefer whitelisting (allow known good values) over blacklisting (deny known bad values).

=== Rule #1 (Query Languages): ===

• Where available (SQL) use prepared statements and stored procedures ([http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet]).

• Do DB and query language specific escaping and encoding on user supplied input.

• Filter control characters ( ' ; -- /**/ ( ) etc.).

=== Rule #2 (Scripting Languages): ===

• Avoid the use of dynamically evaluated code with user input.

• If you can not: perform strict whitelisting of known good values.

• Avoid the use of dynamically evaluated code with user input.

=== Rule #3 (OS Calls): ===

• Do not use calls to system utilities. Every language provides interaction with the operating system. Use language specific packages.

=== Rule #4 (Network Protocols): ===

• If your application talks to network daemons filter protocol specific control characters (%0d, %0a etc.).

=== Additional Defense: ===

• Use a Web Application Firewall (WAF):

    ⁃ Helps you protect closed source applications and third party components.

    ⁃ Can do extended whitelisting and blacklisting until the code is fixed.

• Use the least privileged accounts for all tasks to mitigate the level of access if a component gets compromised. Do sandboxing (chroot) where possible.

← Older revision		Revision as of 20:08, 13 November 2017
Line 1:		Line 1:
−	~~We are looking for a skilled volunteer to help build the OWASP Injection Cheatsheet! If interested, please email jim@owasp.org~~	+	#REDIRECT [[Injection_Prevention_Cheat_Sheet]]
−
−	~~In the meantime, please enjoy the rest of the OWASP Cheatsheet series.~~
−
−	~~{{Cheatsheet_Navigation}}~~

← Older revision	Revision as of 20:14, 23 March 2011
Line 1:	Line 1:
	+	We are looking for a skilled volunteer to help build the OWASP Injection Cheatsheet! If interested, please email jim@owasp.org

	+	In the meantime, please enjoy the rest of the OWASP Cheatsheet series.
	+
	+	{{Cheatsheet_Navigation}}

← Older revision		Revision as of 04:57, 4 April 2010
Line 1:		Line 1:
−	~~= Introduction<br> =~~

−	~~== Problem Description ==~~
−
−	Injection vulnerabilities are a form of '''data becomes code''' issue. The transition from data to code often happens due to ''in-band'' control characters, which mark the beginning (and end) of a commando block. Injected data can be (if syntactically correct) interpreted by an interpreter performing various tasks on the given input. An "interpreter" here is anything that receives and executes commands. Injection attacks are usually server and web application centric attacks with perfectly valid application layer traffic and is thus hard to detect for classic network security components.
−
−	~~== 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 (''Golden Rule''): ===~~
−
−	~~• Perform proper input validation.~~
−
−	~~• Prefer whitelisting (allow known good values) over blacklisting (deny known bad values).~~
−
−	~~=== Rule #1 (Query Languages): ===~~
−
−	• Where available (SQL) use prepared statements and stored procedures ([http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet]).
−
−	~~• Do DB and query language specific escaping and encoding on user supplied input.~~
−
−	~~• Filter control characters ( ' ; -- /**/ ( ) etc.).~~
−
−	~~=== Rule #2 (Scripting Languages): ===~~
−
−	~~• Avoid the use of dynamically evaluated code with user input.~~
−
−	~~• If you can not: perform strict whitelisting of known good values.~~
−
−	~~• Avoid the use of dynamically evaluated code with user input.~~
−
−	~~=== Rule #3 (OS Calls): ===~~
−
−	~~• Do not use calls to system utilities. Every language provides interaction with the operating system. Use language specific packages.~~
−
−	~~=== Rule #4 (Network Protocols): ===~~
−
−	~~• If your application talks to network daemons filter protocol specific control characters (%0d, %0a etc.).~~
−
−	~~=== Additional Defense: ===~~
−
−	~~• Use a Web Application Firewall (WAF):~~
−
−	~~    ⁃ Helps you protect closed source applications and third party components.~~
−
−	~~    ⁃ Can do extended whitelisting and blacklisting until the code is fixed.~~
−
−	~~• Use the least privileged accounts for all tasks to mitigate the level of access if a component gets compromised. Do sandboxing (chroot) where possible.~~