我正在开发一个将 HSTS 标头添加到 Web 应用程序的项目。
作为为此的准备工作,我仅使用 default-src https 指令在报告模式下添加了 CSP 标头。目的是评估违规行为并决定添加 HSTS 标头是否会破坏任何用例。
问题:
- 这是一个有价值的方法吗?
- 使用这种方法,我们会错过哪些 HSTS 场景?
- 如果它们与我上面描述的不同,推荐的方法是什么?
我正在开发一个将 HSTS 标头添加到 Web 应用程序的项目。
作为为此的准备工作,我仅使用 default-src https 指令在报告模式下添加了 CSP 标头。目的是评估违规行为并决定添加 HSTS 标头是否会破坏任何用例。
问题:
如果您仅在服务器上使用 https,我会认为这很明显。你有设置https吗?您是否设置了重定向以强制将所有http 请求重定向到 https?这些问题应该很容易通过查看您的服务器配置来回答,我认为您不需要 CSP 来回答这些问题。如果两者的答案都不是“是”,那么您为什么要考虑 HSTS?
CSP 支持不是通用的(尽管公认 HSTS 也不是),并且,对于这些东西,通常是较旧的、不太常见的浏览器会崩溃,因为您可能会测试常见的浏览器,因此您的方法是否会给您带来所需的信心继续进行是有争议的。
您应该注意的一件事是,如果您使用的是 includeSubDomains 标志。如果它影响的服务器数量超出您的预期,这可能会导致问题,但 CSP 无济于事,因为您可能只会在您认为会受到影响的服务器上设置 CSP。更多信息在这里:https ://serverfault.com/questions/665234/problems-using-hsts-header-at-top-level-domain-with-includesubdomains 。
另请注意,一旦实施 HSTS,就无法再在浏览器中绕过证书错误。不是说你应该这样做,而是这个标志的另一个不是每个人都知道的有意效果。
请注意,解决 HSTS 问题的唯一方法(例如,如果您发现您毕竟需要 http),除了删除标头并等待策略过期之外,是将最大年龄设置回零并希望人们访问您的网站使用 https 来获取这个新的 HSTS 策略并覆盖之前的策略。使用 Chrome 可以手动查看和删除策略,但如果您有大量访问者并且不知道在没有完全重新安装的情况下使用其他浏览器执行此操作的任何方法,则这是不切实际的。
最好的方法是充分了解 HSTS 是什么,以及上面的注意事项,然后从低到期日开始,只要您没有遇到任何问题,就慢慢建立它。
还有预加载列表,但我会远离它,直到你运行它至少 6 个月没有问题。