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 "Codereview-Input Validation"

From OWASP
Jump to: navigation, search
m (Review - spelling etc)
Line 5: Line 5:
  
 
===Data Validation===
 
===Data Validation===
All external input to the system shall undergo input validation. The validation rules are defined by the business requirements for the application. If possible an exact match validator should be implemented. Exact match only permits data that confroms to an expected value. A "Known good" approach (whitelist) is a little weaker but more flexible are common. Known good only permits characters/ASCII ranges defined within a whitelist. Such a range is defined by the business requirements of the input field. The other approaches to data validation are "known bad" which is a black list of "bad characters", not future proof and would need maintenance. "Encode bad" would be very weak as it would simply encode characters considered "bad" to a format which is deemed not at affect the functionality of the application.
+
All external input to the system shall undergo input validation. The validation rules are defined by the business requirements for the application. If possible an exact match validator should be implemented. Exact match only permits data that conforms to an expected value. A "Known good" approach (white-list) is a little weaker but more flexible are common. Known good only permits characters/ASCII ranges defined within a white-list. Such a range is defined by the business requirements of the input field. The other approaches to data validation are "known bad" which is a black list of "bad characters", not future proof and would need maintenance. "Encode bad" would be very weak as it would simply encode characters considered "bad" to a format which is deemed not at affect the functionality of the application.
  
 
===Business Validation===
 
===Business Validation===
  
Business validation is concerned with business logic. Understanding to the business logic is required prior to reviewing the code which performs such logic. Business validation could be used to limit the value range or a transaaction inputted by a user or reject input which does not make too much business sense.
+
Business validation is concerned with business logic. Understanding to the business logic is required prior to reviewing the code which performs such logic. Business validation could be used to limit the value range or a transaction inputted by a user or reject input which does not make too much business sense.
Reviewing code for business validation can also invlude rounding errors or floating point issues which may give rise to issues such as integer overflows which can dramatically damage the bottom line.
+
Reviewing code for business validation can also include rounding errors or floating point issues which may give rise to issues such as integer overflows which can dramatically damage the bottom line.
 
===Canonicalization===
 
===Canonicalization===
 
Canonicalization is the process by which various equivalent forms of a name can be resolved to a single standard name, or the "canonical" name.
 
Canonicalization is the process by which various equivalent forms of a name can be resolved to a single standard name, or the "canonical" name.
 
===References===
 
===References===
[[Reviewing_Code_for_Data_Validation|Reviewing code for Data validaiton]]
+
[[Reviewing_Code_for_Data_Validation|Reviewing code for Data Validation]]

Revision as of 20:36, 26 August 2008

OWASP Code Review Guide Table of Contents

Introduction

Input validation is one of the most effective application security technical controls. It can mitigate numerous vulnerabilities (but not all). Input validation is more than checking form field values. The chapter of transactional analysis talks about this.

Data Validation

All external input to the system shall undergo input validation. The validation rules are defined by the business requirements for the application. If possible an exact match validator should be implemented. Exact match only permits data that conforms to an expected value. A "Known good" approach (white-list) is a little weaker but more flexible are common. Known good only permits characters/ASCII ranges defined within a white-list. Such a range is defined by the business requirements of the input field. The other approaches to data validation are "known bad" which is a black list of "bad characters", not future proof and would need maintenance. "Encode bad" would be very weak as it would simply encode characters considered "bad" to a format which is deemed not at affect the functionality of the application.

Business Validation

Business validation is concerned with business logic. Understanding to the business logic is required prior to reviewing the code which performs such logic. Business validation could be used to limit the value range or a transaction inputted by a user or reject input which does not make too much business sense. Reviewing code for business validation can also include rounding errors or floating point issues which may give rise to issues such as integer overflows which can dramatically damage the bottom line.

Canonicalization

Canonicalization is the process by which various equivalent forms of a name can be resolved to a single standard name, or the "canonical" name.

References

Reviewing code for Data Validation