Skip to content

Commit

Permalink
Add clarifications to the explanatory text
Browse files Browse the repository at this point in the history
  • Loading branch information
tghosth committed Mar 13, 2024
1 parent 39a9719 commit 4644b8e
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions 5.0/en/0x13-V5-Validation-Sanitization-Encoding.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,11 +14,11 @@ With modern web application architecture, output encoding is more important than

## V5.1 Input Validation

Properly implemented input validation controls, using positive allow lists and strong data typing, can sometimes eliminate injection attacks. However, there are instances where input validation may not be effective for security purposes. For example, a valid email address or URL can still be used to conduct successful attacks.
Properly implemented input validation controls, using positive allow lists and strong data typing, provides a useful defense in depth measure for security. However, except in specific cases it is generally not intended to prevent specific attacks.

Input validation is still important for security hygiene and should be applied to all inputs where possible.
Input validation is still important for security hygiene and should be applied to all inputs where possible. Since input validation is not a complete security strategy, one should also make use of sandboxing, sanitization, encoding and parameterization.

Sometimes input validation is not going to be helpful for security, other times it will help it to a moderate degree, whilst other times it will be fundamental for security defense. It depends on the type of data and the use of that data to determine how effective input validation will be. Because input validation is not a complete security strategy, one should also make use of sandboxing, sanitization, encoding and parameterization.
It also important to remember that potentially dangerous input can come from a variety of sources including HTML form fields, REST requests, URL parameters, HTTP headers, cookies, files on disk, databases, external APIs, etc. As such, it is important to take a broad view on where these controls need to be enforced.

| # | Description | L1 | L2 | L3 | CWE |
| :---: | :--- | :---: | :---: | :---: | :---: |
Expand Down

4 comments on commit 4644b8e

@elarlang
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are some lines of text, but I struggle to put my finger on, what is the exact message it tries to deliver. If I read this it gives me an impression, that input validation is good extra defense in depth, but it is not always necessary - but this is not true.

Points to cover (not in this wording):

  • Line 1 - Input validation is required to have data in the correct and expected format, defined by business logic rules.
  • Line 2 - If data is valid but it causing problems when processed by program code, then it's not a correct place to solve those issues by input validation - e. g. it is not allowed to remove HTML tags from a text field, but instead application need to be able to process and display it correctly whatever it contains.

I would move line 3 to 1st.

@jmanico
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would also like to note that sometimes, input validation is a super powerful security measure. For example, when a piece of input should be an integer within a certain range, validating that a variable truly is an integer in that range provides excellent injection protection.

@elarlang
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jmanico - it may work in practice as "dirty hack", but for me, this is fundamentally incorrect. To avoid injection, you need to handle output - handling the output must not rely on business logic rules and should be independent and built the way "I can handle correctly whatever the data comes".

@jmanico
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jmanico - it may work in practice as "dirty hack", but for me, this is fundamentally incorrect. To avoid injection, you need to handle output - handling the output must not rely on business logic rules and should be independent and built the way "I can handle correctly whatever the data comes".

I agree with you mostly. For example not parameterizing a variable even if its an int can be a performance problem. So yea, I hear you Elar.

PS: This is how most web application firewalls work.

Please sign in to comment.