# 利用 HTTP Security Headers 提升站点安全性 产品不断迭代，安全却很少关注，这在小团队司空见惯吗？ 前两天拿到一份站点的安全检测报告：  例举几点： * 你是否将 Mysql、Redis、Mongo 等端口暴露在公网？ * 你是否采用 22、3306这种极易被扫描的默认端口？ * 你是否强制使用 HTTPS？是否将HTTP重定向到了HTTPS？ * 你是否设置了 HTTP Security Headers？ ... 还有检测不出来的，如果用了云服务器，是否禁用了root用户以密码登录？是否开启了安全组？... 本文整理几个 **HTTP Security Header**，属于图中的 Application Security部分。将用 nginx 来演示这些配置。通过文中材料链接可查看更详细的信息。 ## HTTP Security Header 检测报告提示：未遵守 [X-Frame-Options](https://developer.mozilla.org/zh-CN/docs/Web/HTTP/X-Frame-Options)、[X-XSS-Protection](https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/X-XSS-Protection)、[HSTS](https://developer.mozilla.org/zh-CN/docs/Glossary/HSTS)、[X-Content-Type-Options](https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/X-Content-Type-Options) 的最佳实践，这几个都是 HTTP Response header。nginx 配置demo将在最下面给出。 ### X-Frame-Options X-Frame-Options 用来告诉浏览器，页面能不能以 frame、 iframe、 object 形式嵌套在其他站点中，用来避免点击劫持(clickjacking)攻击。例如用下面代码将百度以 **iframe** 嵌入到自己的站点，然后监听 **iframe** 事件做些其他事情，用户如果不看URL估计以为自己在用百度。 ```html <iframe src="https://www.baidu.com/" width="100%" height="100%" frameborder="no"></iframe> ```  可选值： * **DENY**：页面不允许在 frame 中展示 * **SAMEORIGIN**：same origin，页面可以在相同域名页面的 frame 中展示 * **ALLOW-FROM uri**：页面可以在指定来源的 frame 中展示 ### X-XSS-Protection 用于处理跨站脚本攻击 ([XSS](https://developer.mozilla.org/en-US/docs/Glossary/XSS))。 可选值： * 0：禁止XSS过滤 * 1：启用XSS过滤。 如果检测到跨站脚本攻击，浏览器将清除页面中不安全的部分，但页面仍然可以访问。 * 1;mode=block：启用XSS过滤。 如果检测到攻击，浏览器将直接阻止页面加载。 ### HSTS HSTS(HTTP Strict Transport Security，[RFC 6797](https://tools.ietf.org/html/rfc6797)) **HTTP严格传输安全** ，指告诉浏览器自动从HTTP切换到HTTPS(当然，站点得支持HTTPS)。 举例说明，如下图(nginx 将http重定向到https)： * 左边没加HSTS配置，301正常重定向，耗时 **80ms** ; * 右边配置了HSTS，浏览器利用cache，直接将HTTP转成了HTTPS，耗时 **2ms**，免去了重定向过程。 状态从 **301** 变成了 **307 Internal Redirect** 即浏览器内部跳转。  ### X-Content-Type-Options **X-Content-Type-Options** 用来提示客户端一定要遵循在 [Content-Type](https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Content-Type) 首部中对  [MIME 类型](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types) 的设定，而不能对其进行修改，用于禁用了客户端的 [MIME 类型嗅探](https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Basics_of_HTTP/MIME_types#MIME_sniffing)行为。 当资源缺失 MIME 类型或设置了错误的 MIME 类型时，浏览器可能会通过查看资源来进行MIME嗅探。简单来说，就是如果浏览器不确定资源是什么，就会看看资源的内容，X-Content-Type-Options 就是让浏览器不要干这个事情。 可选值： * nosniff：sniff 即嗅探。 ### nginx 配置demo > [HTTP Strict Transport Security (HSTS) and NGINX](https://www.nginx.com/blog/http-strict-transport-security-hsts-and-nginx/) 通过nginx **add_header** 指令在 response 中添加如下header，可以根据需要调整。add_header 可以作用于nginx的 http、server、location。 ```nginx server { listen 80; server_name chenyongjun.vip; location / { add_header X-Frame-Options "DENY"; add_header X-Xss-Protection "1;mode=block"; add_header X-Content-Type-Options "nosniff"; add_header Strict-Transport-Security "max-age=31536000; includeSubdomains; preload"; } } ``` 关于Strict-Transport-Security： * max-age 必要，单位s，表示HSTS Header过期时间，通常设置为1年，即31536000秒。 * includeSubDomains 可选，表示子域名是否开启HSTS保护。 * preload 可选，如果需要将域名加入到浏览器内置列表才需配置 * nginx 1.7.5 or NGINX Plus R5 以上支持这么写， `add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;`，always用于确保所有的response设置了该header ## Spring Security 如果你使用了 [Spring Security](https://docs.spring.io/spring-security/site/docs/4.0.x/reference/html/headers.html)，默认会利用 **HeaderWriterFilter** 将上面的安全配置全部写入 response。 如果你想在流量入口统一做安全设置，可以禁用或调整应用中 Spring Security 配置。修改你自定义的 **WebSecurityConfig**： ```java @Configuration public class WebSecurityConfig extends WebSecurityConfigurerAdapter { @Override protected void configure(HttpSecurity http) throws Exception { // 下面的所有实例代码都在这里 } } ``` ### 修改配置 **禁用 Secure Header** ```java http.headers().disable(); ``` **禁用X-Frame-Options** > 其他选项不一一列出 ```java http.headers().frameOptions().disable(); ``` ### nginx 中剔除配置 如果应用中启用了 HTTP Secure Headers，但是最终返回的Response需要剔除某个配置。在不改代码前提下，可以通过nginx来剔除，例如从response中剔除X-Frame-Options配置： ```nginx proxy_hide_header X-Frame-Options; ``` ## 小结 本文主要是想增长一丢丢安全意识，这些配置倒是次要的，还有更多的安全相关配置，需要时查查资料就好。