5.3.10 need more beef

[jmanico]

5.3.10 does not explain the "how". Perhaps change:

5.3.10 | Verify that the application protects against XPath injection or XML injection attacks. (C4) | ✓ | ✓ | ✓ | 643

to:

5.3.10 | Verify that the application protects against XPath injection or XML injection attacks with XML-specific encoding. (C4) | ✓ | ✓ | ✓ | 643

[elarlang]

5.3.9
Jim, please search for opened issues before opening new ones - 5.3.9 will be deleted as it is #1470

Proposal can go to #1427

[jmanico]

5.3.9 Jim, please search for opened issues before opening new ones - 5.3.9 will be deleted as it is #1470

Proposal can go to #1427

Gotchya, I changed this to only impact 5.3.10 and moved the other suggestion to #1427

[elarlang]

it's quite close to 5.3.1. One option is to put XML to the list there.

#	Description	L1	L2	L3	CWE
5.3.1	[MODIFIED] Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, CSS, URL parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as ねこ or O'Hara). (C4)	✓	✓	✓	116

[elarlang]

Some ideas:

• XML injection - classical encoding issue for output document generation, can be part of of 5.3.1
• XPath injection - is query technique (and not output document generation). Naturally does not belong to 5.3.1 list.

So, maybe we need to kind of split the requirement and have separate way for XPath injection with parameterized or encoded and sanitized recommendations?

[elarlang]

The issue requires outcome from #1589

[tghosth]

Ok so I think XML injection should be covered by the current 5.3.1 text:

#	Description	L1	L2	L3	CWE
5.3.1	[MODIFIED] Verify that output encoding for an HTTP response/HTML document/XML document is relevant for the context required, such as encoding the relevant characters for HTML elements, HTML attributes, HTML comments, JavaScript, CSS, or HTTP headers, to avoid changing the message or document structure.	✓	✓	✓	116

As such, I propose we focus this down to XPath injection:

#	Description	L1	L2	L3	CWE
5.3.10	[MODIFIED] Verify that the application is protected against XPath injection attacks by using query parameterization or precompiled queries, or sanitization if there is no other alternative.	✓	✓	✓	643

@elarlang

[elarlang]

Yes, it is aligned with my idea (#1556 (comment)). Just no slahes to 5.3.1.

[tghosth]

I will fix 5.3.1 here: ca4ced9

Opened #2016 Please either approve or let me know if there are any objections or concerns :) @elarlang

[jmanico]

I suggest dropping "or sanitization if there is no other alternative" - we do not want to encourage it and it's not necessary.