Strict-Transport-Security header in Cuba::Safe::SecureHeaders is dangerously strict!
grempe opened this issue · comments
The setting of the 'Strict-Transport-Security' security header is by default set to:
"Strict-Transport-Security" => "max-age=631138519; includeSubdomains; preload"
The use of this header is good, but for a default setting (encouraged to use in the docs with no explanation of its repercussions) it is far to strict and could cause a developers other websites to inadvertently become inaccessible for long periods of time to any browser that visits the SecureHeader Cuba app over HTTPS.
In detail:
max-age=631138519;
This is good to set, but it is set for a very long period for a developer that may only be in testing mode. This value represents 20.013 years. That means that any browser that successfully visits that site will never allow it to be visited over a non-secure HTTP connection for at least 20 years. The only way to reset is for the server to set it to '0' explicitly and then the browser user has to visit the site again. I would suggest a more reasonable value of 1 month, or 2628000 seconds.
includeSubdomains
This is an optional value and it has potentially far-reaching effects and should not be included in a default setup. By setting this, you are telling every browser that visits this site over an HTTPS connection successfully (even once) that ALL SUBDOMAINS of this domain shall also be REQUIRED to visit over an https connection. So for example, if there is a pre-existing www.example.com website which does not have a TLS certificate, and then the developer of this Cuba mini-app decides to setup this secure little mini-site on HTTPS. From now on every browser that visited the mini-site will refuse to load the www site over simple HTTP since it is not protected by TLS!! This (spec optional) setting should be removed from Cuba's defaults.
preload
preload is another optional part of the spec, and is dangerous to include in a default setup. By having this set you are requesting (or allowing to be requested) that this domain be permanently hard-coded into the Chrome browser (and others who use their service) that they should only be allowed to see the site over HTTPS. This setting, when present, might allow an attacker to add the site on the HSTS preload site (https://hstspreload.appspot.com) and force all Chrome users to only allow access to this domain, and all sub-domains, over HTTPS. This option should also be removed from the defaults.
All of this is well documented here:
https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security
Twitter Secure Headers project, also does not use the optional attributes:
https://github.com/twitter/secureheaders
You should also include instructions for how to override specific security settings as appropriate for a Cuba app in the docs. I am doing so in my Cuba app with something like this which seems to be working as expected:
require 'cuba'
require 'cuba/safe'
...
Cuba.plugin Cuba::Safe::SecureHeaders
Cuba.settings[:default_headers].merge!({"Strict-Transport-Security" => "max-age=2628000"})
...
Cuba.define do
...
end
@grempe You analysis is excellent, thanks a lot! Do you think it would be OK to release these changes in 3.6.0, the next minor version? I ask in case you foresee any problems regarding backward compatibility.
I think next release would be fine. I think that any sites that are using security headers that pick up the change will apply that to users when they next visit with a browser over an HTTPS connection. Cheers.
Plz ignore commit 532e97c, it was the same thing on a botched pull request that I have since thrown away. The second one is the appropriate one to pull in.
Any thoughts on when the next release of Cuba may be? Looks like only docs changes in the last couple of months since this was pulled in. Might be good to get this out there.
@grempe You are absolutely right! I just released version 3.6.0 which includes this change. Again, thanks for your help!
Awesome! I don't see it here though.
@grempe Added it just now, thanks!
FYI. For anyone visiting this issue later.