-
-
Notifications
You must be signed in to change notification settings - Fork 673
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
Adding clarity for 1.5.1 and 5.1.4 (related 5.1.3, 1.8.1) #1552
Comments
I would use JSON and XML schema validation separately, 5.1.4 can send more clear message as "allow-listed pattern" for validation. JSON and XML schemas are covered with requirements:
|
Thanks @elarlang - would you suggest we delete 5.1.4 as is then? It seems really JSON/XML specific. |
No, I don't suggest that. With requirement 1.5.1 must be defined, how some data must be validated and with 5.1.4 analyzt must follow the ruleset from 1.5.1 and verify that. The word schema maybe was directing you to JSON and XML fields, but otherwise I think those requirements are in correct place.
|
Yes, schema implies JSON and XML schema and is throwing me off for that requirement, its confusing and need fixing IMO. |
While I see how you can see where schema may imply JSON or XML, it really is using the definition meaning "identified or specified pattern". Unless we have another requirement that addresses pattern specific data fields like email address, SSN, phone number, etc., I'd say we leave 5.1.4 as is. If the word "schema" is confusing for many, maybe we swap it for something like "specified patterns". |
Need to make sure we don't overlap with 1.8.1:
|
Any further comments? |
If 1.5.1 is pre-condition for 5.1.4, then 1.5.1 should be also level 1... |
And second thing - we need to take also 5.1.3 into the game and make clear separation, which requirement is meant for what. |
Note: for updated version, move to comment #1552 (comment) Related requirements 1.5.1, 1.8.1, 5.1.3, 5.1.4.
I think 5.1.3 and 5.1.4 are overlapping at the moment and those should be more clear. I think those can be merged (and maybe logically related fields from 5.1.4 as separate requirement) Goals for requirements:
If we have agreement on the requirement goals, then we can start finetune them. |
n+1'th time - you can not develop (and later test) without having documentation requirements in place. |
I agree. But ASVS is already very bulky. Some things are already implied. And no one - ever - got hacked because of missing documentation. |
If you don't have documentation, on how you need to implement something, there's quite a big chance that you will not implement it (correctly), and... you may get hacked because of that. But in general, at the moment we create documentation requirements AND implementation requirements. What we will do or how we organize the documentation requirement is up for discussion (in #1831) and out of scope for this issue. |
I surrender and see the value of 1.5.1. I think we are all in sync now. |
Ok @elarlang I think there are some tweaks I would make here based on the "documentation and implementation" concept. I would also like to differentiate this from 5.1.3 by referring to "business specific" data which might have business logic rules for validating it. Also, I don't really know what output requirements are and I am not sure how they are relevant here.
What do you think? |
(I created https://github.dev/OWASP/ASVS/tree/v5_refresh_1552 but haven't done anything with it yet) |
I think the word "business" can be misleading, that something must be related to finances. The goal from my point of view is that all logically related things must match with each other. |
So instead of "business specific" I was thinking of "semantically meaningful" but I worry that this would not be clear enough. Do we just want to call it data which is expected to be in a particular format? @elarlang |
I agree with this. Good observation @elarlang. I would just suggest: Verify that all data is validated according to the rules for the relevant data item or combination of items. |
Wordsmithing needed, but I think we should mention or spotlight the "logical combination of related items". |
Can I suggest: |
My suggestion:
Verify that each data item is individually validated according to its specific rules, and that related data items are validated together to meet requirements as a group.
|
I had a discussion with @elarlang and based on your input @jmanico @ryarmst we came up with some split and refined requirements:
|
This is great over all. For 1.5.5 I suggest removing the "reasonable". Perhaps: Verify that input validation rules specify how to ensure the logical and contextual consistency of combined data items, such as checking that suburb and zipcode match. I think 5.1.7 can go away. It's a reduced duplicate of 1.5.5 |
n+xth time. It is documentation+implementation combination. Both are required. |
That's fine, but I still think it's unnecessary. But it's no big deal, go for it. |
Suggest we augment 5.1.4 from:
to:
The text was updated successfully, but these errors were encountered: