全栈工程师修炼指南
全栈工程师修炼指南

如何让HTTPS站点更加安全? 这篇HTTPS安全加固配置最佳实践指南就够了

[TOC]

前置知识推荐了解
HTTPS原理介绍以及证书签名的申请配置 ( https://blog.weiyigeek.top/2019/10-21-10.html )

SSL与TLS协议原理和证书签名生成实践指南 ( https://blog.weiyigeek.top/2019/10-21-12.html )

原文链接
HTTPS安全优化配置最佳实践指南简述 ( https://blog.weiyigeek.top/2022/4-6-11.html )

0x02 HTTPS安全加固指南

描述: 当你的网站上了 HTTPS 以后，可否觉得网站已经安全了，其实不然前面说过想要部署TLS是非常容易，只需要证书与密钥文件然后根据中间件的配置ssl方法进行配置即可，默认的配置通常不满足https的安全需要，所以我们还需要进一步着重在于 HTTPS 网站的 Header 的相关配置。

1.连接安全性和加密选择

安全加固实践

  • 1.1) 建议部署配置 (HSTS) HTTP Strict Transport Security (HTTP 严格传输安全HSTS)响应头，它是TLS的安全网旨在确保即使在配置问题和实施错误的情况下安全性仍然保持不变,如果要使用HSTS我们只需要在网站添加一个新的响应头Strict-Transport-Security。再设置该响应头之后将会告诉浏览器只使用 HTTPS 连接到目标服务器，并且还防止一些潜在的中间人攻击，包括 SSL 剥离、会话 cookie 窃取。
# 语法演示:
Strict-Transport-Security: max-age=Strict-Transport-Security: max-age=; includeSubDomains
Strict-Transport-Security: max-age=; preload

# 配置示例: 浏览器防止指定站点以及将来的子域名都采用 HTTPS，最大年龄为1年(31536000)，同时还允许预加载（加快速度）：
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

# Nginx
# HSTS (ngx_http_headers_module is required) (63072000 seconds == 两年)
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
  • 2.2) 建议部署配置HPKP(HTTP Public Key Pins)响应头, 指示浏览器只与提供的 SSL/TLS 的 HASH 相符或存在于同一证书链的服务器相连接。简单的说如果 SSL/TLS 证书以一种意想不到的方式发生了变化，浏览器就无法连接到主机，这主要是针对受信任证书颁发机构（CA）或流氓 CA 证书颁发的伪造证书，用户可能会被骗安装。

例如，浏览器连接到 https://weiyigeek.top，它存在这个头。header 告诉浏览器，如果证书 key 匹配，或者在发出证书链中有一个 key 匹配，那么在将来才会再次连接。其他的指令组合是可能的。它们都极大地减少了攻击者在客户端和合法主机之间模拟主机或拦截通信的可能性。

Public-Key-Pins: max-age=5184000; pin-sha256="+oZq/vo3Kcv0CQPjpdwyInqVXmLiobmUJ3FaDpD/U6c="; pin-sha256="47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU="

温馨提示: 设置 HSTS header Strict-Transport-Security 长的生命周期，即 max-age 的时间不能小于15552000，最好是半年及以上。
温馨提示: 确定是否需要为您的站点使用 PKP, 如果要是使用它请注意在SSL/TLS密钥需要更新时建立备份计划, 优先创建备份密钥和离线存储。


2.站点内容安全（Content security）

安全加固实践

  • 2.1) 避免混合 HTTPS 和 HTTP 内容(Mixed HTTPS and HTTP Content), 如果 HTTPS 部署在主站上，请将任何地方的所有内容都 HTTPS 化（全站 HTTPS）。

  • 2.2) 建议配置良好的内容安全策略(CSP - Content Security Policy)响应头, 它可以帮助抵御跨站点脚本（XSS）和其他注入攻击等攻击，现在主流的浏览器都是支持CSP头的。

一个理想的CSP策略是基于白名单的方法，不允许任何东西，除了明确允许的内容，它还限制了 javascript 的来源和允许操作。

# 从限制性策略开始在必要时放松。
Content-Security-Policy: default-src 'none';

# 现在让我们允许自托管 scripts、images、CSS、fonts 和 AJAX，以及 jQuery CDN 托管脚本和 Google Analytics:
Content-Security-Policy: default-src 'none'; script-src 'self' https://code.jquery.com https://www.google-analytics.com; img-src 'self' https://www.google-analytics.com; connect-src 'self'; font-src 'self'; style-src 'self';

# 一个不那么严格的策略
Content-Security-Policy: default-src 'self';

# 更少的限制性策略,然后添加限制，非常不建议如此使用。
Content-Security-Policy: default-src '*';
  • 2.3) 建议配置X-Frame-Options非标准的响应头, 它规定了控制站点是否可以放置在