Dynamically generated HTML

[tghosth]

Jim previously mentioned a requirement:

Verify that dynamically generated HTML is constructed safely using templates or frameworks that auto-encode outputs.

Jim says in a comment below that table that this is not sufficiently covered in 5.2.5 and that "I think safely building HTML (encoding and similar) and avoiding template injection (avoid server side template assembly) are different controls."

We need to assess if there are any other related requirements and how to proceed with this.

[tghosth]

@set-reminder in 3 days @tghosth to look at this

[octo-reminder]

⏰ Reminder
Saturday, July 27, 2024 12:00 AM (GMT+02:00)

in @tghosth to look at this

[octo-reminder]

🔔 @tghosth

in @tghosth to look at this

[elarlang]

What case it should cover that is not covered by current requirements 5.2.5 and 5.3.1?

#	Description	L1	L2	L3	CWE
5.2.5	[MODIFIED] Verify that the application protects against template injection attacks by not allowing templates to be built based on untrusted input. Where there is no alternative, any untrusted input being included dynamically during template creation must be sanitized or strictly validated.	✓	✓	✓	94
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

[jmanico]

When dynamically assembling HTML, sometimes escaping is not enough. Sometimes we need to sanitize blobs of user driven HTML or CSS, and sometimes escaping is not enough like in the case of a URL driven by a user that lands in a SRC or similar attribute.

Any kind of HTML assembly will require a very tactical combination of contextual encoding (for data that you want to display exactly as the user typed it in), strict validation (like in the case of URL's or other content that cannot be safely escaped) and content sanitization (like in the case of rich content like user-driven HTML or CSS that cannot otherwise be validated).

[elarlang]

For sanitization we also have:

#	Description	L1	L2	L3	CWE
5.2.1	[MODIFIED] Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized using a well-known and secure HTML sanitization library or framework feature.	✓	✓	✓	116
5.2.2	Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.	✓	✓	✓	138

For unintended content execution we have:

#	Description	L1	L2	L3	CWE
5.2.4	Verify that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed.	✓	✓	✓	95

[jmanico]

There are a few small edge cases not covered, but otherwise this collection of requirements are fairly complete.

[tghosth]

@jmanico do you think any of the existing requirements could be enhanced to cover the edge cases or do you think these are best left to a cheat sheet?

[jmanico]

These edge cases are so extensive I suggest we stick to a cheat sheet.

[tghosth]

Ok so I think I will close this issue if that is ok @jmanico ?

[jmanico]

Agreed 👍🏼