Java Input Validation Best Practices: Canonicalization of Input Data

Where should input validation be conducted?

What is the purpose of canonicalization in input validation?

What should happen when input validation fails?

What is the recommended approach for validating data types?

What should be validated in addition to request data?

What should be done when hazardous input must be allowed?

What is the primary benefit of using a centralized input validation routine for the whole application?

Why is it important to specify character sets for all input sources?

What is the purpose of encoding input to a common character set before validating?

What is the recommended approach for validating protocol header values in both requests and responses?

What is the benefit of using an 'allow' list rather than a 'deny' list for data type validation?

What is the purpose of validating data from untrusted sources, such as databases and file streams?

What is the purpose of validating data range and length?

Input Validation Guidelines

Input validation should be conducted on a trusted system (server-side) to prevent client-side manipulation.
All data sources should be identified and classified into trusted and untrusted sources.
Data from untrusted sources (databases, file streams, etc.) should be validated to ensure security.
A centralized input validation routine should be used for the whole application to maintain consistency.
Character sets (e.g. UTF-8) should be specified for all input sources to ensure canonicalization.
Input should be encoded to a common character set before validation to prevent encoding attacks.
All validation failures should result in input rejection to prevent malicious data from entering the system.
If the system supports UTF-8 extended character sets, validation should occur after UTF-8 decoding is completed.
All client-provided data should be validated before processing to prevent attacks.
Protocol header values in both requests and responses should only contain ASCII characters to prevent header injection attacks.
Data from redirects should be validated to prevent redirection attacks.
Validation should focus on expected data types using an "allow" list rather than a "deny" list to prevent unexpected data types from entering the system.
Data range and length should be validated to prevent buffer overflow attacks.
If potentially hazardous input must be allowed, additional controls should be implemented to mitigate risks.
Extra discrete checks should be used if the standard validation routine cannot address some inputs.
Canonicalization should be used to address obfuscation attacks that use non-standard encoding techniques.

Test your knowledge of secure input validation techniques, including conducting validation on a trusted system, classifying data sources, and encoding input to a common character set. Learn how to protect your application from malicious input and ensure data integrity.