proposal: 1.12.2 (50.5.2) move/merge to 12.5.2 (50.5.1)

[elarlang]

Related issue:

#	Description	L1	L2	L3	CWE
1.12.2	Verify that user-uploaded files - if required to be displayed or downloaded from the application - are served by either octet stream downloads, or from an unrelated domain, such as a cloud file storage bucket. ~~Implement a suitable Content Security Policy (CSP) to reduce the risk from XSS vectors or other attacks from the uploaded file.~~		✓	✓	646

edit: CSP part is now removed from the requirement text.

CWE-646 - Reliance on File Name or Extension of Externally-Supplied File

Current requirement contains many parts:

• are served by either octet stream downloads, or from an unrelated domain, such as a cloud file storage bucket
  • Point: to avoid them to be executed in Same-Site and Same-Origin scope as HTML, JavaScript or other client-side code
  • Covered by current 12.5.2, also a bit related to requirement from issue #1009
• Implement a suitable Content Security Policy (CSP) to reduce the risk from XSS vectors.
  • Point: duplicates clearly Content-Security-Policy requirement
  • Covered by current 14.4.3
• or other attacks from the uploaded file
  • Point: "other point" (none)

#	Description	L1	L2	L3	CWE
12.5.2	Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content.	✓	✓	✓	434
14.4.3	[MODIFIED] Verify that a Content Security Policy (CSP) response header is in place that helps mitigate impact for XSS attacks like HTML, DOM, CSS, JSON, and JavaScript injection vulnerabilities.	✓	✓	✓	1021

CWE-434 - Unrestricted Upload of File with Dangerous Type

Proposals:

• remove duplicate CSP part from the requirement (done, duplicate removed)
• merge 1.12.2 to 12.5.2 as those serve the same goal

[tghosth]

Why did you reopen @elarlang?

[elarlang]

Why did you reopen @elarlang?

Only CSP part remove quick-fix is done, merge to make.

[tghosth]

Requirement history:

#	Description	L1	L2	L3	CWE
1.12.2	[MODIFIED] Verify that user-uploaded files - if required to be displayed or downloaded from the application - are served by either octet stream downloads, or from an unrelated domain, such as a cloud file storage bucket.		✓	✓	646
1.12.2	Verify that user-uploaded files - if required to be displayed or downloaded from the application - are served by either octet stream downloads, or from an unrelated domain, such as a cloud file storage bucket. Implement a suitable Content Security Policy (CSP) to reduce the risk from XSS vectors or other attacks from the uploaded file.		✓	✓	646
1.12.2	Verify that user-uploaded files - if required to be displayed or downloaded by the application - are served from an unrelated domain, such as a cloud file storage bucket or similar, to reduce the risk of image or other files exploiting XSS vectors via using content security policy and same origin policy restrictions.		✓	✓	646

The item was originally added in commit https://github.com/OWASP/ASVS/commit/7809c0bfa06dc4623ae0fcc5253dfcd794e80f41.

Based on the discussion in #455, it sounds like the main purpose was to promote sandboxing and not just for XSS but in general.

I would support keeping this as a separate requirement but moving it to section 12.5 as a practical/implementation requirement.

[elarlang]

Mapping it here: https://github.com/OWASP/ASVS/issues/1009

[jmanico]

Suggest a small grammar change for 1.12.2 (please do not use dashes in requirements, they are not proper punctuation).

1.12.2	[MODIFIED] Verify that user-uploaded files, if required to be displayed or downloaded from the application, are served by either octet-stream downloads or an unrelated domain, such as a cloud file storage bucket.		✓	✓	646

[elarlang]

Update: those requirements are moved now to the Web Frontend Security category:

V50.5 Unintended Content Interpretation

#	Description	L1	L2	L3	CWE
50.5.1	[GRAMMAR, MOVED FROM 12.5.2] Verify that direct requests to uploaded files will never be executed as HTML and JavaScript content.	✓	✓	✓	434
50.5.2	[MODIFIED, MOVED FROM 1.12.2] Verify that user-uploaded files - if required to be displayed or downloaded from the application - are served by either octet stream downloads, or from an unrelated domain, such as a cloud file storage bucket.		✓	✓	646

Proposal to merge them is still valid.

[tghosth]

So we now also have:

#	Description	L1	L2	L3	CWE
50.5.3	[ADDED, DEPRECATES 14.4.2] Verify that to prevent browsers from rendering content or functionality in HTTP responses in an incorrect context, security controls are in place (e.g. not serving the content unless headers indicate it is the correct context, Content-Security-Policy: sandbox, Content-Disposition: attachment, etc). For example when an API or other resource is loaded directly.	✓	✓	✓

This seems to replace 50.5.1 definitely. What about 50.5.2?

[tghosth]

@elarlang any idea what the next stage is here

[elarlang]

The next step is to build a requirement for addressing the attack vector, that an attacker can upload a file that causes a so-called XSS attack in the same origin scope when accessed directly or served incorrectly.

But to have the brainpower to do that is another question.

[jmanico]

Do one of these work for you?

Verify that user-uploaded files, if required to be displayed or downloaded from the application, are served by an octet stream downloads and from an unrelated domain, such as a cloud file storage bucket.

or

Verify that user-uploaded files, if required to be displayed or downloaded from the application, are served from an unrelated domain, such as a cloud file storage bucket, to mitigate XSS and other security risks.

[elarlang]

From @tghosth in https://github.com/OWASP/ASVS/issues/1406#issuecomment-1871064630 about 50.5.3

This seems to replace 50.5.1 definitely. What about 50.5.2?

The more I try to solve the issue, the more I also lean towards a solution to merge them all into one requirement. As the principle is already covered, we should spotlight the uploaded files issue in one example at the end of the requirement.

This requirement can be long - it covers so many edge-cases and there are so many different solutions to achieve that.

[jmanico]

How about one of these?

Verify that user-uploaded files, if required to be displayed or downloaded from the application, are handled in a manner that ensures they cannot be executed as HTML or JavaScript content. This can be achieved by serving files as octet-stream downloads with appropriate Content-Disposition and Content-Type headers, or by serving them from an unrelated domain (such as a cloud file storage bucket), to mitigate XSS and other security risks.

or

Verify that user-uploaded files, if required to be displayed or downloaded from the application, are served in a manner that prevents execution as HTML or JavaScript content. Files must be delivered either through octet-stream downloads or from an unrelated domain (such as a cloud storage bucket), with appropriate security headers and validation mechanisms to mitigate risks such as XSS and MIME-type attacks.

[elarlang]

The overlap with 50.5.3 is quite big - the only recommendation that is different is that "serve the content from other domain". Although it takes the same-origin vector down, I'm not sure we should mandate or allow HTML or JavaScript execution from other domain. If there is no reason to execute it with direct HTTP request, then it should not happen.

[tghosth]

haha so now we also have 50.5.4. Reproducing the whole section here:

#	Description	L1	L2	L3	CWE
50.5.1	[GRAMMAR, MOVED FROM 12.5.2] Verify that direct requests to uploaded files will never be executed as HTML and JavaScript content.	✓	✓	✓	434
50.5.2	[MODIFIED, MOVED FROM 1.12.2] Verify that user-uploaded files - if required to be displayed or downloaded from the application - are served by either octet stream downloads, or from an unrelated domain, such as a cloud file storage bucket.		✓	✓	646
50.5.3	[ADDED, DEPRECATES 14.4.2] Verify that security controls are in place to prevent browsers from rendering content or functionality in HTTP responses in an incorrect context (e.g., when an API or other resource is loaded directly). Possible controls could include: not serving the content unless headers indicate it is the correct context, Content-Security-Policy: sandbox, Content-Disposition: attachment, etc.	✓	✓	✓
50.5.4	[ADDED, SPLIT FROM 5.3.3] Verify that context-aware methods are used when handling untrusted data to avoid unintended content execution, such as executing content as HTML instead of displaying it as text.	✓	✓	✓

[tghosth]

@elarlang how many requirements do you think this should be merged down to?

[elarlang]

50.5.1, 50.5.2 and 50.5.3 are for situation, if an HTTP response is executed as HTML or JavaScript (or anything else). Those 3 can be merged to one requirement. The question is mostly, should we have a separate requirement for uploaded files to highlight the widespread issue.

50.5.4 is a separate thing - it is more related to, how dynamic JavaScript builds the HTML document.

[jmanico]

Agreed on 50.5.1, 50.5.2 and 50.5.3 merging. How about:

Verify that user-uploaded files are never executed as HTML or JavaScript, are served as octet stream downloads or from a separate domain, and implement controls (e.g., Content-Security-Policy: sandbox, Content-Disposition: attachment) to prevent incorrect rendering by browsers.

[elarlang]

Jim - you are cutting so many details and keep proposing a separate domain. Please read previous comments.

I prefer we just cover 50.5.1 and 50.5.2 points into current 50.5.3:

Verify that security controls are in place to prevent browsers from rendering content or functionality in HTTP responses in an incorrect context (e.g., when an API, a user-uploaded file or other resource is requested directly). Possible controls could include: not serving the content unless HTTP request headers, such as Sec-Fetch-*, indicate it is the correct context, Content-Security-Policy: sandbox, Content-Disposition: attachment, etc.

edit: finetuned the last sentense

[jmanico]

Sorry @elarlang was moving too fast. I like your version. All is well.

[elarlang]

Tags (the idea: 12.5.2 was moved to 50.5.1 and other 2 requirements were merged into it):

• to new merged requirement [MODIFIED, MOVED FROM 12.5.2, MERGED FROM 1.12.2, 14.4.2]
• 12.5.2 [MOVED TO 50.5.1]
• 1.12.2 [DELETED, MERGED TO 50.5.1]
• 14.4.2 [DELETED, MERGED TO 50.5.1] - previously it the new requirement said "DEPRECATES 14.4.2"

[elarlang]

ping @tghosth - please recheck before I hit the PR.

[tghosth]

@elarlang that all makes sense to me

[tghosth]

Current v50.6.1:

[MODIFIED, MOVED FROM 12.5.2, MERGED FROM 1.12.2, 14.4.2] Verify that security controls are in place to prevent browsers from rendering content or functionality in HTTP responses in an incorrect context (e.g., when an API, a user-uploaded file or other resource is requested directly). Possible controls could include: not serving the content unless HTTP request header fields, such as Sec-Fetch-*, indicate it is the correct context, Content-Security-Policy: sandbox, Content-Disposition: attachment, etc.

@elarlang you mentioned elsewhere that you might want to split this back up? What is your proposal?

[elarlang]

So, the theoretical need is to split it because it contains different details that may require a separate level for the requirement.

User-uploaded files and API responses containing user-controlled data are for sure level 1. If there are other pieces of content, such as some template files in a public folder, then accessing those is not that risky and can be considered a level 3 requirement.

If there is agreement, that the requirement can be level 1 as is, there is no need to split anything. The split is not easy to make without having close-to-duplicate requirements.

[tghosth]

Ok so let's leave it for now, I updated the Google Sheet