OWASP
Duplication on 3rd party Javascript
Current state:
We currently have the following two requirements:
Verify that the application employs integrity protections, such as code signing or subresource integrity. The application must not load or execute code from untrusted sources, such as loading includes, modules, plugins, code, or libraries from untrusted sources or the Internet. (CWE-353)
Verify that if application assets, such as JavaScript libraries, CSS or web fonts, are hosted externally on a Content Delivery Network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset. (CWE-829)
Proposed state:
In my opinion, we are duplicating here and we should merge these to requirements as follows:
10.3.2:
[MODIFIED, MERGED FROM 14.2.3] Verify that the application only loads or executes code or content from untrusted sources if it employs integrity protections, such as code signing or Subresource integrity (SRI). This could include loading includes, modules, plugins, code, or libraries from untrusted sources or using JavaScript libraries, CSS or web fonts hosted by an external provider or Content Delivery Network (CDN). (CWE-829)
14.2.3:
[DELETED, MERGED TO 10.3.2]
I agree 101% with the 10.3.2 proposed modification. The more we emphasize responsible loading of all external components and libraries, the better we all will be. One wonders if there exists a need to have some dedicated allow list resource that defines said external resources and only loads those? or is that opening up a can of worms
Those are duplicates, agree - we need to get rid one of them.
Agree with category choice as well: "V10 Malicious Code > V10.3 Application Integrity" seems better choice than "V14 Configuration > V14.2 Dependency".
What I'm not really happy with, is the length of the requirement. In a way I like the current 14.2.3 more as it is short and clear.
One wonders if there exists a need to have some dedicated allow list resource that defines said external resources and only loads those? or is that opening up a can of worms.
We basically have allow-list of sources covered with requirements:
- 14.2.4 Verify that third party components come from pre-defined, trusted and continually maintained repositories.
- 14.4.3 Verify that a Content Security Policy (CSP) response header is in place that helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection vulnerabilities.
And from this point of view - I would like to avoid the word "untrusted" in the proposed change. We should not take anything from untrusted sources. All we care, is external. What is trusted today, may not be trusted tomorrow when those trusted ones got hacked and SRI point is to cover that case.
I ran into this same issue while on an engagement trying to figure out a good spot to fit the finding. I think this would be highly beneficial if the requirements requiring checks for SRI get merged into its own section.
"Verify that if application assets, such as JavaScript libraries, CSS or web fonts, are hosted externally on a Content Delivery Network (CDN) or external provider,"
Would be good for its own section.
@elarlang I think the use of "untrusted" is important because it is not just external which is untrusted.
What about:
10.3.2:
[MODIFIED, MERGED FROM 14.2.3] Verify that the application loads or executes code or content from sources not under the application's direct control/protection only if it also employs integrity protections, such as code signing or Subresource integrity (SRI). This could include loading includes, modules, plugins, code, or libraries from untrusted sources or using JavaScript libraries, CSS or web fonts hosted by an external provider or Content Delivery Network (CDN). (CWE-829)
@SoftwareSinner sorry I am not sure I understood what you are proposing.
How do you validate this signed code in practice? Is it more build pipeline question?
Maybe we need to keep 2 requirements separately and just take duplicated part (subresource integrity) out of 10.3.2?
So one reason to keep them separate might be to separate client side and server side scenarios. Code signing would only be a server side scenario where for some reason the server was pulling a code module from an external source. It should then be expected to verify the imported module using a public key with the module having been signed on build by the external party.
As from testing perspective those are clearly separate scenarios and require separate permissions as well, I would keep them separately.
My current idea would be to clean up 10.3.2 the way it does not overlap with 14.2.3 - it means 10.3.2 is dealing only with signing code and 14.3.2 dealing with SRI part.
I take your point, how about:
10.3.2
Verify that the application only loads or executes code, modules, content or plugins from sources not under the application's direct control/protection if it employs integrity protections, such as code signing. (CWE-829)
14.2.3:
Verify that if browser assets, such as JavaScript libraries, CSS or web fonts, are hosted externally on a Content Delivery Network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset. (CWE-829)
10.3.2 - change is ok for me
14.2.3 - proposal is to change "application assets" to "browser assets"? For me a "browser assets" relates more with something related only with browser like browser plugin. Following list of examples makes it clear, but I prefer to keep this requirement like it is.
So how about:
14.2.3:
Verify that if client-side assets, such as JavaScript libraries, CSS or web fonts, are hosted externally on a Content Delivery Network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset. (CWE-829)
"Application assets" does not catch the key-point that we are talking about things which will be used client-side in the browse
Just in case - for 10.3.2 CWE change from 353 to 829 was intentional or happened because in the beginning those were seen as duplicates?