Duplicate X-Content-Type-Options headers both with the value nosniff

#85 Change record and Release note is available, setting back to RTBC

Asking from complete ignorance: Is there any web.config equivalent we should consider here for parity?

@xjm Great question. https://serverfault.com/a/904278 suggests it is both possible to do and to prevent duplicate headers, as in the .htaccess changes in this issue. However I think it would be necessary for someone running IIS to test this before we commit such a change.

Great, let's do that then. Thanks!

The web.config file is completely different. This should be done in a follow-up ticket.

Also web.config does not currently do anything with X-Content-Type-Options so it can't be causing the same bug. This fact might be a bug on it's own but it shouldn't be solved here as this issue is about Apache having duplicate headers.

Also a decent number of IIS articles recommend setting this on the site level in the server (i.e. not using web.config - see https://dotnetcoretutorials.com/2017/01/20/set-x-content-type-options-as... for an example).

Opened 📌 Set X-Content-Type-Options header in IIS web.config Active to discuss #99 through #104.

If IIS doesn't have it set at all yet, then @catch, @longwave, and I agreed with a followup.

However, please make note that in general, any issues for .htaccess should consider web.config in the same issue scope. In this case, probably the previous issue should have. We've had frequent issues over the years (both public hardenings and private security issues) where the web.config has not been well-maintained and has not gotten the same fixes, so we always need to evaluate it @Liam Morland. It doesn't get excluded just because it's in a different file, and how issues are scoped is a release management decision.

  # https://httpd.apache.org/docs/current/mod/mod_headers.html.
  Header onsuccess unset X-Content-Type-Options
  Header always set X-Content-Type-Options nosniff

Since we're unsetting all values for the header but only resetting nosniff, I checked to verify that this was the only possible value for it. Per https://fetch.spec.whatwg.org/#x-content-type-options-header:

1. Let values be the result of getting, decoding, and splitting `X-Content-Type-Options` from list.
2. If values is null, then return false.
3. If values[0] is an ASCII case-insensitive match for "nosniff", then return true.
4. Return false.

So at least in the present spec, this solution is OK.

Adding credit for @alexpott for code review and the initial issue report, @Liam Morland, @alex-b, and @Mile23 for work on the patch, @longwave for review and work on the CR and release note, @JoshaHubbers for work on the CR and release note, @effulgentsia for review and work on the patch, @Wim Leers for review and issue triage, and @mr.baileys for review and manual testing. I did not credit @idebr for merging HEAD with no other changes.

I was wondering what happened to the earlier attempts at test coverage, but it seems #3226187: Enable mod_headers on Apache → needs to be addressed for that.

Release notes should always tell the user:

1. What it was before
2. What changed
3. Who might be affected
4. What they should do as a result

The release note was missing the second two, so I added a sentence for that. I similarly expanded the content of the CR with background information on why this header is used in the first place, and put in a code snippet to show exactly what site owners should update. Finally, I linked the CR from the release note.

Committed and pushed to 10.1.x. Thanks!

Added the release note to the draft release notes doc.

I appreciate all the work on this issue. Thanks to everyone involved.

However, please make note that in general, any issues for .htaccess should consider web.config in the same issue scope. In this case, probably the previous issue should have. We've had frequent issues over the years (both public hardenings and private security issues) where the web.config has not been well-maintained and has not gotten the same fixes, so we always need to evaluate it @Liam Morland. It doesn't get excluded just because it's in a different file, and how issues are scoped is a release management decision.

From the security team perspective, I support this paragraph from comment #106. We regularly will get reports "htaccess provides X security benefit that is missing in web.config" and then are in the awkward situation of deciding whether to do a security advisory and release for a fix that affects relatively few people.

I think we should consider it a bug if web.config and htaccess' behavior is different.

xjm → closed merge request !323

Published the CR.

Is this commit eligible for backporting as it is a bugfix?

Changes to .htaccess are usually only made in minor releases unless they are critical. This is not a critical bug - the duplicate header might cause warnings, but it has no actual impact on anything - so to me this is not eligible for backport.

Automatically closed - issue fixed for 2 weeks with no activity.