0021262: Invalid Strict-Transport-Security header when server would already send it anyway - MantisBT - Signup temporarily disabled due to spam

ID	Project	Category	View Status	Date Submitted	Last Update

0021262	mantisbt	security	public	2016-07-11 18:48	2016-10-02 18:41

Reporter	j_schultz	Assigned To	dregad
Priority	normal	Severity	major	Reproducibility	always
Status	closed	Resolution	fixed
Product Version	1.3.0
Target Version	1.3.2	Fixed in Version	1.3.2

Summary	0021262: Invalid Strict-Transport-Security header when server would already send it anyway
Description	My server (Apache 2.4.10 with PHP 5.6.22 on Debian Jessie) is already configured to send HSTS headers for all HTTPS-enabled domains. In http_api.php, Mantis will try to send its own Strict-Transport-Security header, which will make PHP emit the following header value: "max-age=15768000, max-age=7776000" (the former value is my own). I do not think that it should be Mantis' responsibility to send this header, as it very much depends on the server environment if this value can be permanently enabled. For example, if a sysadmin never conciously enabled HTTPS (e.g. only providing a self-signed cert for internal purposes, or they only enabled it temporarily), then all users which accidentally visited the issue tracker's domain will be locked out for a long while because of Mantis. Mantis is in control of its content, so setting Content-Security-Policy is sensible, but Mantis is not in control of the HTTPS configuration, so it should not outsmart the server admin.
Steps To Reproduce	Enable HSTS in your Apache (or similar) config, e.g. <IfModule mod_headers.c> Header always set Strict-Transport-Security "max-age=15768000" </IfModule> Access Mantis.
Tags	No tags attached.

j_schultz 2016-07-11 18:48 reporter ~0053570	By the way, Firefox will log this as an error and presumably as a result not apply HSTS at all.

j_schultz 2016-07-12 08:41 reporter ~0053576	In addition to what I described in the initial bug description, you should be aware that HSTS effectively prevents self-signed certificates (or anything that uses a root cert not in the browser's trust store, e.g. the somewhat popular CAcert certificates: http://www.cacert.org/) from being used with Mantis. This is because HSTS enforces a valid HTTPS certificate, which the server admin may not be able to provide for some reason. I am aware that Let's Encrypt is gaining huge popularity so invalid SSL certs are less an issue than they used to be, but not everyone can use this service, so self-signed certificates are still going to be used in the future and Mantis currently cannot be used with them without manually editing the source code. On the other hand, if the server admin is able to set up a valid HTTPS certificate, they should also be capable of adding the HSTS rule in their server software as well. If an admin uses e.g. Mozilla's best practice SSL config generator (https://mozilla.github.io/server-side-tls/ssl-config-generator/), it will automatically generate the necessary rules for them. Furthermore, due to the way HSTS is currently implemented in Mantis, it is very complicated, if possible at all, to secure other documents served on the same domain using HSTS. You'd either have to disable the server's own HSTS headers completely for the domain, or restrict them to specific folders (excluding the Mantis folder). And even then, Mantis only sends this header for its PHP files, not for the remaining files, which is probably not a big issue but it's still far from optimal. I recommend that Mantis should only send HSTS headers when explicitely instructed by the admin to do so, e.g. through a new config variable.

j_schultz 2016-09-01 09:53 reporter ~0053923	STS still breaks in 1.3.1 with servers that already send the header.

dregad 2016-09-01 10:26 developer ~0053924 Last edited: 2016-09-01 10:29	Sorry I missed your report, which you submitted while I was on vacation. I agree with your conclusion that setting HSTS is not of Mantis' responsibility. EDIT: For the record this was implemented by dhx in 0012881. I suggest to revert the change.

dregad 2016-09-01 10:44 developer ~0053925	Pull request https://github.com/mantisbt/mantisbt/pull/875

MantisBT: master-1.3.x 2e7fac44 2016-09-01 06:30 dregad Committer: vboctor Details Diff	Do not set HSTS header Enabling HTTP Strict-Transport-Security should be a decision made by the system administrator, and implemented at server level, probably site-wide and not just for MantisBT's PHP files. Furthermore, Mantis setting this header causes issues if it is already set for the server (invalid header), and may have unwanted side effects as described in 0021262. This reverts the change implemented to resolve issue 0012881. Fixes 0021262		Affected Issues 0012881, 0021262
	mod - core/http_api.php		Diff File
MantisBT: master 968f83a9 2016-09-01 06:30 dregad Committer: vboctor Details Diff	Do not set HSTS header Enabling HTTP Strict-Transport-Security should be a decision made by the system administrator, and implemented at server level, probably site-wide and not just for MantisBT's PHP files. Furthermore, Mantis setting this header causes issues if it is already set for the server (invalid header), and may have unwanted side effects as described in 0021262. This reverts the change implemented to resolve issue 0012881. Fixes 0021262		Affected Issues 0012881, 0021262
	mod - core/http_api.php		Diff File