5.1.6 needs added clarity

[jmanico]

Suggest change:

5.1.6	[MOVED FROM 1.5.3, LEVEL L2 > L1] Verify that input validation is enforced on a trusted service layer. (C5)	✓	✓	✓	602

to:

5.1.6	[MOVED FROM 1.5.3, LEVEL L2 > L1] Verify that input validation is enforced on a trusted service layer. Avoid client-side validation, which can be easily bypassed. (C5)	✓	✓	✓	602

[elarlang]

Recommendation sends wrong signal, like client-side validation is bad. It is not bad, just from security point of view, you can not rely on that.

[jmanico]

How about:

5.1.6	[MOVED FROM 1.5.3, LEVEL L2 > L1] Verify that input validation is enforced on a trusted service layer. Client-side validation, while still useful for other purposes, which can be easily bypassed from a security perspective. (C5)	✓	✓	✓	602

[mgargiullo]

May I suggest a slight rewrite for clarity:

"Client-side validation, while still useful for other purposes, which can be easily bypassed from a security perspective.
to
"While useful, client-side validation can be easily bypassed and thus is not a valid security treatment."

[elarlang]

More food for brain.

We had similar discussion (#1031 (comment)) for access control requirement 4.1.1:

#	Description	L1	L2	L3	CWE
4.1.1	[MODIFIED] Verify that the application enforces access control rules at a trusted service layer and doesn't rely on controls which an untrusted user could manipulate such as client-side JavaScript.	✓	✓	✓	602

Also, we have a logging requirement that kind of expects, that all input validation is done on the client side, other wise you have a lot of noise to log on the trusted service layer. If input validation is done in the client side, then you have only 2 cases to log as input validation errors:

• validations on the client-side and server-side are out of sync (bug)
• someone is trying to manipulate input validation or making an HTTP request without the expected user-interface (browser) - a potential attack attempt

#	Description	L1	L2	L3	CWE
7.1.3	[MODIFIED] Verify that the application logs security relevant events including successful and failed authentication events, access control failures, deserialization failures, input validation failures and incorrect HTTP requests (including requests with an unexpected HTTP verb). (C5, C7)		✓	✓	778

[elarlang]

Can we go with something like that?
Verify that input validation is enforced on a trusted service layer. Client-Side input validation is recommended to use for better usability.

or

Verify that input validation is enforced on a trusted service layer. Client-Side input validation is recommended to use for better usability but security can not rely on that.

[elarlang]

ping @jmanico @tghosth

[jmanico]

I like it Elar. Small change suggestion:

Verify that input validation is enforced at a trusted server-side layer. While client-side validation improves usability, security must not rely solely on it.

[tghosth]

Minor change:

(We wanted to move away from the "server-side" expression).

Verify that the application is designed to enforce input validation at a trusted service layer. While client-side validation improves usability, security must not rely on it.

This should be added to the new section described here: #1484 (comment)

Should also add an entry to recommendations:

Client-side input validation should be enforced along with the validation at a trusted service layer as this provides a good opportunity to discover when someone has bypassed client-side controls in an attempt to attack the application.

[tghosth]

@elarlang

[tghosth]

@elarlang to create the PR

[tghosth]

Should also add an entry to recommendations:

Client-side input validation should be enforced along with the validation at a trusted service layer as this provides a good opportunity to discover when someone has bypassed client-side controls in an attempt to attack the application.

I have done this with: 6b92836

[tghosth]

Otherwise I think we are good on this one