Topics

[EXT] [CII-badges] Proposal: Stop requiring X-XSS-Protection, require CSP with explanation, for criterion hardened_sites


Jason Dossett
 

This change makes perfect since.

Best,


Jason N. Dossett, Ph.D.
Research Staff Member
Institute for Defense Analyses
4850 Mark Center Drive, Alexandria, VA  22311
Phone:  703-578-2773
Email:   jdossett@...

-----Original Message-----
From: CII-badges@... <CII-badges@...> On Behalf Of David Wheeler
Sent: Tuesday, June 2, 2020 4:49 PM
To: CII-badges@...
Subject: [EXT] [CII-badges] Proposal: Stop requiring X-XSS-Protection, require CSP with explanation, for criterion hardened_sites

*** This email originated outside of IDA. Please verify that you recognize the sender and know the content is safe before proceeding. ***


I propose that for the "hardened_sites" criterion we stop requiring the HTTP header X-XSS-Protection, and that we require CSP & explain why.

Here's the background.

The Linux kernel is failing to meet the "hardened sites" criterion:
https://bestpractices.coreinfrastructure.org/en/projects/34?criteria_level=2#hardened_site

The reason is that those sites' HTTP headers do not include something like this:
X-XSS-Protection: 1

The criterion main text is: "The project website, repository (if accessible via the web), and download site (if separate) MUST include key hardening headers with nonpermissive values."
with these details: "Note that GitHub is known to meet this. Sites such as https://securityheaders.io/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), X-Frame-Options, and X-XSS-Protection. Static web sites with no ability to log in via the web pages may omit the CSP and X-XSS-Protection HTTP hardening headers, because in that situation those headers are less effective."

This issue with the Linux kernel is discussed here:
https://github.com/coreinfrastructure/best-practices-badge/issues/1253

There are two problems. The first is that X-XSS-Protection has not aged well. It's supposed to enable some heuristic protections. These protections are largely unnecessary in modern browsers (CSP is recommended instead), and it's increasingly obvious that this header will never be standardized. Firefox won't add it, Edge has retired it.
Perhaps most importantly, securityheaders.io doesn't even *report* the status of X-XSS-Protection, making it suddenly harder to see this header value for a site... and also providing additional evidence that X-XSS-Protection has outlived its purpose. Details here:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection

The second problem is that while CSP isn't really very helpful on static sites, it's impractical to detect if a site is a static site or not, and we very much *do* want to encourage CSP use. So I propose keeping the main criterion unchanged, but changing these details:

"Note that GitHub is known to meet this. Sites such as https://securityheaders.io/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), X-Frame-Options, and X-XSS-Protection. Static web sites with no ability to log in via the web pages may omit the CSP and X-XSS-Protection HTTP hardening headers, because in that situation those headers are less effective."
To the following:

"Note that GitHub is known to meet this. Sites such as https://securityheaders.io/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), and X-Frame-Options. In theory static web sites with no ability to log in via the web pages could omit CSP with less risk, because in that situation those headers are less effective. However, there's no reliable way to detect that a site is fully static, so we simply require CSP for all such sites."
--- David A. Wheeler
Director of Open Source Supply Chain Security, The Linux Foundation