Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

5.6.2 Adding Server-side validation proposal #2006

Closed
mesutgungor opened this issue Jul 28, 2024 · 13 comments
Closed

5.6.2 Adding Server-side validation proposal #2006

mesutgungor opened this issue Jul 28, 2024 · 13 comments
Labels
7) PR in non-master branch V5 Temporary label for grouping input validation, sanitization, encoding, escaping related requirements _5.0 - prep This needs to be addressed to prepare 5.0

Comments

@mesutgungor
Copy link

In 5.6 Validation and Sanitization Architecture
Although "trusted service layer" covers it, I would propose adding "server-side(back-end) validation" explicitly to make it more clarified.

Current :

# Description L1 L2 L3 CWE
5.6.2 [MODIFIED, MOVED FROM 1.5.3, LEVEL L2 > L1] 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. 602

Proposal

# Description L1 L2 L3 CWE
5.6.2 [MODIFIED, MOVED FROM 1.5.3, LEVEL L2 > L1] 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. Server-side (back-end) validations should be implemented to protect the application against bypassing client-side validations. 602
@elarlang
Copy link
Collaborator

For me the proposed phrase just duplicates the requirement and does not provide anything extra.

@elarlang elarlang added the V5 Temporary label for grouping input validation, sanitization, encoding, escaping related requirements label Jul 28, 2024
@mesutgungor
Copy link
Author

mesutgungor commented Jul 28, 2024

I would partially agree and also mentioned. But It feels like a bit implicit to me
if we divide the requirement

  • The requirement : Verify that the application is designed to enforce input validation at a trusted service layer.
  • How not to do it : While client-side validation improves usability, security must not rely on it.
  • How to do it properly : Server-side (back-end) validations should be implemented to protect the application against bypassing client-side validations.

@ryarmst
Copy link
Contributor

ryarmst commented Jul 28, 2024

Would it be suitable to use the Glossary (Appendix A) to provide an expanded definition of and examples of "trusted service layer"? Notably, the top Google search results for me all come from its use with the ASVS. I see it is currently defined in V1.5.

@tghosth tghosth added 1) Discussion ongoing Issue is opened and assigned but no clear proposal yet _5.0 - prep This needs to be addressed to prepare 5.0 labels Jul 29, 2024
@tghosth
Copy link
Collaborator

tghosth commented Jul 29, 2024

I would partially agree and also mentioned. But It feels like a bit implicit to me if we divide the requirement

  • The requirement : Verify that the application is designed to enforce input validation at a trusted service layer.
  • How not to do it : While client-side validation improves usability, security must not rely on it.
  • How to do it properly : Server-side (back-end) validations should be implemented to protect the application against bypassing client-side validations.

I think the requirement could be slightly clearer based on this structure but I agree with Ryan that I prefer to keep the trusted service layer terminology but make sure it is sufficiently covered in the glossary

@elarlang
Copy link
Collaborator

#1553 - in this issue, there is a discussion of how and why we reached the current requirement text.

@tghosth
Copy link
Collaborator

tghosth commented Aug 12, 2024

Ok so I added a minor clarification to 5.6.2 and also added trusted service layer to the glossary. @mesutgungor

#2018 for your approval @elarlang

@elarlang
Copy link
Collaborator

Well, seems that the PR is merged already.

I really don't think we need " as it can be bypassed" to the requirement.

bypass - for me it is a situation, when there is proper defense in place but there is some mistake in program code that gives you opportunity to send the parameters in a way that security mechanisms are not exectuted.

In this context is not the case - client-side validation is just a usability on the client side and from the server-side/trusted service layer point of view, when communicating with the service directly, there is nothing to bypass. You just skip the UI part.

@tghosth
Copy link
Collaborator

tghosth commented Aug 15, 2024

Can you think of a better way to word this?

@elarlang
Copy link
Collaborator

We just don't need this phrase in the requirement, it does not give anything extra.

Trusted means that we are not concerned that an untrusted user will be able to bypass the control.

The description part, maybe we should go with message like (input for wordsmithing):
Trusted means that we are not relying on a client-controlled layer such as JavaScript executed in the browser as it is possible to communicate with service directly without JavaScript code providing any effect to the data quality.

@elarlang elarlang added the next meeting Filter for leaders label Aug 15, 2024
@tghosth
Copy link
Collaborator

tghosth commented Aug 15, 2024

Discussed with @elarlang

@set-reminder 7 days @tghosth to rollback addition to requirement and update the glossary.

For glossary:

...that an untrusted user will be able to bypass or skip the layer or controls implemented at that layer.

Copy link

octo-reminder bot commented Aug 15, 2024

Reminder
Thursday, August 22, 2024 12:00 AM (GMT+02:00)

@tghosth to rollback addition to requirement and update the glossary.

@tghosth tghosth removed the next meeting Filter for leaders label Aug 15, 2024
Copy link

octo-reminder bot commented Aug 21, 2024

🔔 @tghosth

@tghosth to rollback addition to requirement and update the glossary.

tghosth added a commit that referenced this issue Aug 25, 2024
@tghosth
Copy link
Collaborator

tghosth commented Aug 25, 2024

Ok @elarlang can you confirm your approval on #2025

tghosth added a commit that referenced this issue Aug 26, 2024
@tghosth tghosth added 7) PR in non-master branch and removed 1) Discussion ongoing Issue is opened and assigned but no clear proposal yet labels Sep 2, 2024
@tghosth tghosth closed this as completed in fb7aab3 Sep 9, 2024
tghosth added a commit that referenced this issue Sep 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
7) PR in non-master branch V5 Temporary label for grouping input validation, sanitization, encoding, escaping related requirements _5.0 - prep This needs to be addressed to prepare 5.0
Projects
None yet
Development

No branches or pull requests

4 participants