Input Validation Cheat Sheet - Revision history

Dominique RIGHETTO: Point to the official site

2019-07-15T14:13:08Z

Point to the official site

Thunder-Son: Migration to GitHub

2019-02-14T12:41:00Z

Migration to GitHub

Show changes

Jmanico: /* Other Cheatsheets */

2017-09-11T06:08:17Z

‎Other Cheatsheets

Pawel Krawczyk: /* Whitelisting vs blacklisting */ Validating free-form Unicode text=

2017-06-15T11:24:33Z

‎Whitelisting vs blacklisting: Validating free-form Unicode text=

Pawel Krawczyk: restructure a bit

2017-05-16T12:35:09Z

restructure a bit

Pawel Krawczyk: Implementing input validation

2017-05-16T10:19:47Z

Implementing input validation

Pawel Krawczyk: /* Goal of Input Validation */

2017-05-15T13:17:02Z

‎Goal of Input Validation

Pawel Krawczyk: /* Goal of Input Validation */ update, internal links

2017-05-15T13:13:49Z

‎Goal of Input Validation: update, internal links

Pawel Krawczyk: /* White List Regular Expression Examples */ US zip code

2017-05-15T12:54:09Z

‎White List Regular Expression Examples: US zip code

Tony Hsu HsiangChih: /* Beware of "special" files */

2017-03-29T08:15:09Z

‎Beware of "special" files

← Older revision		Revision as of 14:13, 15 July 2019
Line 4:		Line 4:
	The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!		The Cheat Sheet Series project has been moved to [https://github.com/OWASP/CheatSheetSeries GitHub]!

−	Please visit [https://~~github~~.~~com/OWASP/CheatSheetSeries/blob/master~~/cheatsheets/Input_Validation_Cheat_Sheet.md Input Validation Cheat Sheet] to see the latest version of the cheat sheet.	+	Please visit [https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html Input Validation Cheat Sheet] to see the latest version of the cheat sheet.

@@ Line 167: / Line 167: @@
 Dave Wichers - dave.wichers [at] aspectsecurity.com
-== Other Cheatsheets ==
+= Other Cheatsheets =
 {{Cheatsheet_Navigation_Body}}

@@ Line 37: / Line 37: @@
 White list validation is appropriate for all input fields provided by the user. White list validation involves defining exactly what IS authorized, and by definition, everything else is not authorized. If it's well structured data, like dates, social security numbers, zip codes, e-mail addresses, etc. then the developer should be able to define a very strong validation pattern, usually based on regular expressions, for validating such input. If the input field comes from a fixed set of options, like a drop down list or radio buttons, then the input needs to match exactly one of the values offered to the user in the first place.
-The most difficult fields to validate are so called 'free text' fields, like blog entries. However, even those types of fields can be validated to some degree. For example, you can at least exclude all non-printable characters (except acceptable white space, e.g., CR, LF, tab, space), and define a maximum length for the input field.
+===Validating free-form Unicode text===
 ===Regular expressions===

@@ Line 11: / Line 11: @@
 == Goals of Input Validation ==
-Input validation is performed to ensure only properly formed data is entering the workflow in an information system, preventing malformed data from persisting in the database and triggering malfunction of various downstream components.
+Input validation is performed to ensure only properly formed data is entering the workflow in an information system, preventing malformed data from persisting in the database and triggering malfunction of various downstream components. Input validation should happen as early as possible in the data flow, preferably as soon as the data is received from the external party.
-Input Validation is not the ''primary'' method of preventing [[XSS (Cross Site Scripting) Prevention Cheat Sheet|XSS]], [[SQL Injection Prevention Cheat Sheet|SQL Injection]] and other attacks which are covered in respective [[OWASP Cheat Sheet Series|cheat sheets]] but can significantly contribute to reducing their impact if implemented properly.
+Data from all potentially untrusted sources should be subject to input validation, including not only Internet-facing web clients but also backend feeds over extranets, from suppliers, partners, vendors or regulators[https://badcyber.com/several-polish-banks-hacked-information-stolen-by-unknown-attackers/], each of which may be compromised on their own and start sending malformed data.
 == Input validation strategies==
 Input validation should be applied on both '''syntactical''' and '''semantic''' level. Syntactic validation should enforce correct syntax of structured fields (e.g. SSN, date, currency symbol) while semantic validation should enforce correctness of their ''values'' in the specific business context (e.g. start date is before end date, price is within expected range).
 == Implementing input validation==
@@ Line 28: / Line 32: @@
 * Regular expressions for any other structured data covering the whole input string (^...$) and '''not''' using "any character" wildcard (such as "." or "\S")
-== White List Input Validation ==
+=== Whitelisting vs blacklisting ===
-It is always recommended to prevent attacks as early as possible in the processing of the user’s (attacker's) request. Input validation can be used to detect unauthorized input before it is processed by the application. Developers frequently perform black list validation in order to try to detect attack characters and patterns like the ' character, the string 1=1, or the &lt;script&gt; tag, but this is a massively flawed approach as it is typically trivial for an attacker to avoid getting caught by such filters. Plus, such filters frequently prevent authorized input, like O'Brian, when the ' character is being filtered out. For more information on XSS filter evasion please see the [[XSS Filter Evasion Cheat Sheet]].
+White list validation is appropriate for all input fields provided by the user. White list validation involves defining exactly what IS authorized, and by definition, everything else is not authorized. If it's well structured data, like dates, social security numbers, zip codes, e-mail addresses, etc. then the developer should be able to define a very strong validation pattern, usually based on regular expressions, for validating such input. If the input field comes from a fixed set of options, like a drop down list or radio buttons, then the input needs to match exactly one of the values offered to the user in the first place.
-White list validation is appropriate for all input fields provided by the user. White list validation involves defining exactly what IS authorized, and by definition, everything else is not authorized. If it's well structured data, like dates, social security numbers, zip codes, e-mail addresses, etc. then the developer should be able to define a very strong validation pattern, usually based on regular expressions, for validating such input. If the input field comes from a fixed set of options, like a drop down list or radio buttons, then the input needs to match exactly one of the values offered to the user in the first place. The most difficult fields to validate are so called 'free text' fields, like blog entries. However, even those types of fields can be validated to some degree. For example, you can at least exclude all non-printable characters (except acceptable white space, e.g., CR, LF, tab, space), and define a maximum length for the input field.
+The most difficult fields to validate are so called 'free text' fields, like blog entries. However, even those types of fields can be validated to some degree. For example, you can at least exclude all non-printable characters (except acceptable white space, e.g., CR, LF, tab, space), and define a maximum length for the input field.
 Developing regular expressions can be complicated, and is well beyond the scope of this cheat sheet. There are lots of resources on the internet about how to write regular expressions, including: http://www.regular-expressions.info/ and the [[OWASP Validation Regex Repository]].

@@ Line 10: / Line 10: @@
 This article is focused on providing clear, simple, actionable guidance for providing Input Validation security functionality in your applications.
-== Goal of Input Validation ==
+== Goals of Input Validation ==
 Input validation is performed to ensure only properly formed data is entering the workflow in an information system, preventing malformed data from persisting in the database and triggering malfunction of various downstream components.
 Input Validation is not the ''primary'' method of preventing [[XSS (Cross Site Scripting) Prevention Cheat Sheet|XSS]], [[SQL Injection Prevention Cheat Sheet|SQL Injection]] and other attacks which are covered in respective [[OWASP Cheat Sheet Series|cheat sheets]] but can significantly contribute to reducing their impact if implemented properly.
 == White List Input Validation ==

@@ Line 28: / Line 28: @@
 == White List Regular Expression Examples ==
-Validating a Zip Code (5 digits plus optional -4)
+Validating an U.S. Zip Code (5 digits plus optional -4)
   ^\d{5}(-\d{4})?$

@@ Line 93: / Line 93: @@
 *"crossdomain.xml" allows cross-domain data loading in Flash, Java and Silverlight.  If permitted on sites with authentication this can permit cross-domain data theft and CSRF attacks.  Note this can get pretty complicated depending on the specific plugin version in question, so its best to just prohibit files named "crossdomain.xml" or "clientaccesspolicy.xml".
 *".htaccess" and ".htpasswd" provides server configuration options on a per-directory basis, and should not be permitted.  See http://en.wikipedia.org/wiki/Htaccess
 ==Upload Verification==