5.2.2 sounds like input validation

[tghosth]

This requirement is in the sanitization section but sounds like input validation. The CWE also doesn't make sense to me.

#	Description	L1	L2	L3	CWE
5.2.2	Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.	✓	✓	✓	138

[elarlang]

edit: Maybe should be solved here: #1552

[elarlang]

Actually, it's valid requirement. Point for sanitization is, if input validation can not be used, you need to send valid and safe input to next component (downstream) and therefore you need to be sure, that it only contains allowed characters and is with expected/safe length.

[elarlang]

Is there any certain problem to discuss or is there a need for improvement? I think it is suitable for "covering all sanitization cases" which does not have separate requirements per situation.

ping @tghosth

[tghosth]

You think it is like a catch-all or something? It does seem a little vague...

[tghosth]

Verify that unstructured data is sanitized to before being used in any other potentially dangerous context not already listed in this section.

Thought about this but we don't love the fact that it references other requirements.

On the other hand, not sure how to accomplish this as a "last resort/catch-all requirement" without doing so.

[tghosth]

Need to think more about it.

[tghosth]

I now think this is a duplicate of 5.1.3.

I think we should do as follows:

#	Description	L1	L2	L3	CWE
5.1.3	[MODIFIED, MERGED FROM 5.2.2] Verify that all input, including unstructured data, is validated using positive validation, with an allowed list of characters, values or patterns, and an appropriate maximum length.	✓	✓	✓	20

#	Description	L1	L2	L3	CWE
5.2.2	[DELETED, MERGED TO 5.1.3]

What do you think @elarlang ?

[elarlang]

I stand for my comment in #1640 (comment)

Actually, it's valid requirement. Point for sanitization is, if input validation can not be used, you need to send valid and safe input to next component (downstream) and therefore you need to be sure, that it only contains allowed characters and is with expected/safe length.

For me the requirement must stay and I'm ok with the requirement as it is. Also, I have pointed and quoted to this requirement many times as the reason to not have some other requirement. So it's clear no for me to remove it.

[tghosth]

Ok so in that case maybe this clashes with the new 5.3.14 and we need to merge them @elarlang?

#	Description	L1	L2	L3	CWE
5.3.14	[ADDED] Verify that output encoding is relevant for the interpreter and context required in any context where a potentially dangerous interpreter, not mentioned above, is being used.		✓	✓

[tghosth]

This requirement is important for a situation where output encoding is not possible.

We should be clear that sanitization is required when there is no standard encoding or escaping that can be performed. Maybe in the intro text for the section.

Suggested update discussed with @elarlang:

#	Description	L1	L2	L3	CWE
5.2.2	[MODIFIED] Verify that data being passed to a potentially dangerous context is sanitized beforehand to enforce safety measures, such as only allowing characters which are safe for this context and trimming input which is too long.	✓	✓	✓	138

@set-reminder 7 days @tghosth to open a PR and also check intro text.

[octo-reminder]

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

@tghosth to open a PR and also check intro text.

[octo-reminder]

🔔 @tghosth

@tghosth to open a PR and also check intro text.

[tghosth]

Fix to requirement in #2028 (@elarlang to review)

(Change to intro text will be tracked via #2027 and updated separately)