对于开发者而言，网络安全的重要性不言而喻。任何一处代码错误、一个依赖项漏洞或是数据库的端口暴露到公网，都会有可能直接送你上热搜。

那么，哪里可以找到详细的避雷指引呢？OWASP's top 10 清单太短了，而且它更关注的是漏洞罗列，而非对预防。相比之下，ASVS 是个很好的列表，但还是满足不了实际需求。

本文这份清单将介绍 72 个实操要点，让你全方位保护你的 Web 应用程序。各位看官，准备入坑啦！

一、浏览器端的威胁防御

1、用且仅用 HTTPS，防范网络攻击

众所周知，一个安全的应用需要对浏览器和 Web 服务器之间的所有连接进行加密。此外，建议禁用一些旧的密码套件和协议。使用 HTTPS 时，仅加密网站的“敏感”部分是不够的。如非这样，攻击者可以截获某个未加密的 HTTP 请求，然后伪造来自服务器的响应，返回恶意内容。幸运的是，HTTPS 目前是很容易做到的。我们可以通过 Let's Encrypt

继续我们的清单，下一个是 HSTS 它与 HTTPS 密切相关。

2、使用 HSTS 和预加载来保护用户免受 SSL 剥离攻击

HSTS 可以防止 SSL 剥离攻击。所谓的 SSL 剥离攻击也就是：网络上的攻击者截获浏览器发出的第一个 HTTP 请求（通常是未加密的），并立即伪造对该请求的回复，假装是服务器并将连接降级为明文 HTTP。

值得注意的是，HSTS 仅在用户至少成功访问了一次应用程序的情况下才能生效。为了克服这个限制，可以把我们的网站提交到 /app1/ 和 /app2/，是非常危险的。因为浏览器会认为它们是同源应用，也就是同样的服务主机、端口和模式。正因为是同源应用，它们将对彼此有完全的访问权限。任何影响其中一个的漏洞都会同样影响到另外一个。

因此，我们需要给每个应用一个独立的域名。所以，这种情况下应该设置为：/ 和 /

注意：位于同一个域名下的子域名是可以为整个域名设置 Cookie 的。例如 可以为 。允许为一个站点设置 Cookie 有时会给会话固定等类型的漏洞以可乘之机。公共后缀列表可以用来应对该问题。此外，也可以通过将 Cookie 命名为 __Host- 来防止其被子域名所覆盖。

24、谨慎采用 CORS（跨域资源共享）

浏览器的安全模型大部分是依赖于同源策略，它可以防止应用的跨域读取。而 CORS（跨域资源共享）则是一种允许网站进行跨域资源访问的手段。所以，决定使用它之前，最好先搞清楚自己是否真的需要。

如果你在 的服务需要被来自 的 GET 请求访问，那么可以在 服务上指定如下header:

如果你有个公开的服务接口（比如说一个提供给互联网上 JavaScript 客户端使用的计算器服务），那么你可以指定一个随机的来源：

如果你只想让有限的几个域名访问它，那么可以在程序中读取请求的 Origin header，进行比对后处理。不过，建议使用现成的库来操作，不要徒手撸，很容易出错。

默认情况下，跨域资源共享是不带用户凭证的。但如果在 Web 服务器端指定如下 header，则将允许携带：

这对 header 组合相当危险。因为它会使跨域访问具备已登录用户的权限，并使用该权限来访问网站资源。所以，如果你不得不使用它，务必小心为上。

仅允许所需要的 HTTP 方法，从而最小化攻击面。

28、合理使用 WebSockets， 避免反跨站请求伪造等漏洞

WebSockets 迄今还是比较新的技术，技术文档较少使用它难免会有些风险。所以，采用时务必要做到以下几点：

• 对连接进行鉴权如果使用的是基于 Cookie 的鉴权机制，且 WebSocket 服务器与应用服务器在同一个域名下，那就可以在 WebSocket 中继续使用已有的会话。不过切记要对请求源进行验证！如果不是基于 Cookie ，可以在系统中创建一个单次使用、有时间限制并与用户 IP 绑定的授权令牌，用该令牌对 WebSocket 进行授权。
• 对连接源进行确认理解 WebSockets 的一个关键点在于要知道同源策略对其是无效的。任何一个能与你的系统建立 WebSocket 连接的网站，在使用 Cookie 鉴权的时候，都是可以直接获得用户信息的。因此，在 WebSocket 握手时，必须要确认连接源。可以通过验证请求头中的 Origin 参数来确认。

如果想要做到双重保险，可以采用反跨站请求伪造令牌作为 URL 参数。但针对每个任务则需要创建一次性的独立令牌，而不要直接使用反跨站请求伪造令牌，因为后者主要是用来为应用的其它部分提供安全保障的。

29、采用 U2F 令牌或客户端证书，保护系统关键用户免受钓鱼攻击

如果系统可能会面临钓鱼攻击的威胁，说人话也就是，“如果存在这样的可能性：攻击者创建一个假的网站，骗取管理员/CEO 或其它用户的信任，从而盗取其用户名、密码和验证码”，那么就应该使用 U2F 令牌或客户端证书来防止这种攻击，这样的话即使攻击者有了用户名、密码和验证码也无法得逞。

备注：强调钓鱼防护对于一般用户而言往往会带来不必要的麻烦。然而，提供多一种可选项对终端用户而言也非坏事。此外，向用户提前告知钓鱼攻击的危险也是非常必要的。

30、针对跨站点泄露进行保护

跨站点泄露是一系列浏览器边信道攻击。这种攻击使恶意网站可以从其它 Web 应用程序的用户中推测出信息。

这种攻击存在已有时日，但是浏览器端却是最近才开始添加针对性的预防机制。可以在 这篇文章 中了解关于该类攻击的更多细节以及应该采取的安全控制措施。

二、服务器端的威胁防御

其次，是服务器端的威胁防御，这里从应用系统、基础设施、应用架构、应用监控、事件响应等不同侧面，归纳了如下建议：

，如果运行成功，则说明你没有对外部网络连接做出适当的限制。如何处理此类问题，一般则取决于基础设施。

针对外部的 TCP/UDP/ICMP 连接，一般可以通过以下方式禁用：

• 网关防火墙，如果有的话；
• 如果是老式服务器，可以采用本地的防火墙（例如 iptables 或 Windows 防火墙）；
• 如果使用了 Kubernetes，可采用网络策略定义。

DNS 处理起来稍微麻烦一点，我们通常需要允许对一些 hosts 的访问。

• 如果有本地的 hosts 文件，那就很简单，可以采取上面的任何一种方式来将 DNS 彻底禁用；
• 如果没有，那么你需要在你上游的 DNS 中配置一个私有的区域，在网络层限制仅能访问该指定的 DNS 服务器。这个私有区域内只允许对一些预先指定的 hosts 的访问。

52、跟踪 DNS 记录，防止子域名劫持

子域名劫持发生场景举例如下：

• 假如我们拥有一个域名 ，然后创建了一个别名从 映射到 ；
• 这次促销活动结束后， 域名也到期了；
• 但是，从 到 的别名映射仍存在；
• 如果有人购买了这个到期的域名，那么 便可以直接指向该域名；
• 如果攻击者在 域名下提供一些恶意内容，那么便可以通过 域名直接访问到；

因此，需要随时留意你的 DNS 记录。如果需要处理的类似情况较多，强烈建议你做一个自动监控方案。

的应用程序使用 auth0 进行鉴权。

• 该应用程序访问内部 API 服务 ）发起 HTTP 请求，那就需要立刻引起关注。又或者你的系统尝试访问 /etc/passwd。这两种情况都表示有人已经发现了我们系统中的漏洞。

  60、收集 Web 服务器事件

  对 Web 服务器软件，至少要对访问日志和错误日志进行收集，收集后发送到集中式的日志服务器。在突发事件响应时，这将辅助我们快速理清时间线。

  61、收集网络应用程序防火墙（WAF）日志

  如果你像上文推荐使用了网络应用程序防火墙（WAF），那么也对这个日志进行收集。但不用针对这个日志设置报警，因为它基本上会收到来自互联网各种各样的问题，而且不部分是你不用担心的。

  一旦对我们的系统进行了监控和加固，攻击者将难以快速定位系统漏洞，即使最终发现，我们也能快速了解情况。

  但仅了解情况是不够的，还需要做出如下准备：

  • 快速分析系统日志，了解当前状况和需采取的对应措施
  • 在应用防火墙等产品中，快速对个别 url 地址和参数做出限制
  • 如有需要，快速关停系统

  系统地考虑一下“可能会出现哪些问题”并据此做出调整。设计一个新的系统时，越早开始这一步越好。当对系统发生改变时，再重新梳理一遍这个过程。

  小王：如果攻击者攻破了我们连接了互联网的服务器，怎么办？

  小王：好吧！这就说明我们在这里存在着一个信任关系，我们认为连接了互联网的服务器是不会被攻破的。我们可以信任这一点吗？

  小陈：未必吧！有一百种可能导致我们的服务器被黑掉，例如我们代码中存在的脆弱性，或者依赖中存在的脆弱性，或者是我们 Web 服务器所安装软件的脆弱性。

  小王：好吧！那就让我们打破这层信任关系。接下来该做些什么呢？

  小陈：我们这样来分解一下系统：创建一些内部的接口用来实际访问数据库，由此以来，前端的 Web 服务器就不能直接访问后台的所有东西。

  小王：这是个好办法！除此以外，还有其它什么可能出问题呢？

  小陈：嗯，如果黑客攻破了我们的内网呢？

  小王：那所有东西都要丢失了，因为内网里服务器之间的连接都是未加密的。

  这就是威胁模型，它不需要多么复杂。使用这种方式，来找出系统中可能存在的威胁。

  通过技术控制手段，防止代码未经他人审核便提交入库。这是构建安全开发环境的基础，因为它可以做到：

  • 如果攻击者攻陷了一个开发人员的电脑，或者是开发人员自身企图发起攻击，将不能直接将恶意代码迁入代码库；
  • 如果开发人员的错误导致引入了有漏洞的代码，很可能在被其他人检查时及时发现。

  65、自动化持续集成管道，仅允许简单访问

  开发人员应该有权限触发 Jenkins 构建，且 Jenkins 权限配置也仅该如此，不要再允许其它权限。单个开发人员应该不能在构建阶段引入任意代码。当然，如果像上文推荐的强制性地采用了代码审查，Jenkinsfile 也可以保存在版本管理工具中。

  如果是构建容器镜像，可以把对镜像签名作为构建的一步。将签名密钥存储在安全的地方。构建阶段需要访问密钥，但是杜绝将密钥与 Jenkinsfile 一起存储在版本管理工具中。更好的方式是将密钥存储在 HashiCorp Vault 之类的地方，然后在构建时再进行拉取。

  67、持续集成管道中加入静态应用程序扫描器

  在持续集成管道中使用 SpotBugs 和 Find-Sec-Bugs（或者根据你所采用的技术栈进行选择）之类的工具。它们可以帮你在部署代码之前发现已知的漏洞。

  此外，也可以作为 IDE 的插件安装在开发人员的电脑上，在代码迁入之前就运行这些工具进行检查。

  68、构建时对依赖进行检查，保证最小的依赖集

  应用程序中依赖的每个软件包都是一个风险来源。通过依赖，我们拉取了第三人的代码并在我们的应用服务器上执行，所以，必须要搞清楚我们依赖的这个软件包是什么，为什么会依赖它？

  • 仅使用我们所信任的依赖。它们必须是广泛使用和广为人知的；
  • 采用构建框架，对依赖进行确认。

  此外，严格控制应用服务器的对外连接，从而避免后门的存在。

  69、对依赖进行安全扫描

  使用 OWASP 依赖检查工具对依赖中常见的安全问题进行扫描。除了在持续集成管道中，也可以在开发人员的开发环境运行这些工具。

  70、持续集成管道对镜像进行安全扫描

  如果采用了容器化技术，可以使用 Trivy 等工具对容器镜像进行一些常规漏洞的扫描。

  71、自动化部署和签名验证

  开发人员可以有权限到生产环境中部署，但是权限范围应该控制在前阶段已经构建和签名过的特定镜像，而不是直接访问生产服务器。如果是使用 Kubernetes，可以通过 Notary 或开放策略代理来验证待部署镜像的签名。

  72、设置一个安全人员

  一个人的精力是有限的。我们不能期望每个开发人员都精通渗透测试或是安全工程师。正如你不能期望所有的安全专家都是优秀的开发人员一样。因此，可以在团队中设置一个专门关注安全的人员，主要与开发人员、架构师进行交流，帮助保护我们的应用程序并在团队中传播安全意识。

  保证应用程序的安全性，光靠避免漏洞时不够的，必须全面通盘考虑，主动进行防御。这里对一些主要方法进行了总结：

  • 使用最新版本的的软件组件来执行危险的操作，如身份验证、访问控制、加密、访问数据库或解析 XML，并确保正确配置了这些组件，例如 XML 解析时禁用外部实体。
  • 使用平台提供的安全控制，例如反跨站请求伪造保护。
  • 对安全控制进行集中化处理，特别是身份验证和访问控制，从而避免一些遗漏，如在某些控制器方法上忘记对安全进行控制。
  • 使用 Web 应用程序防火墙，防止应用程序漏洞被发现和被利用。
  • 通过限制对文件、网络和系统资源的访问来对应用程序进行限制。
  • 利用威胁模型发现架构中的威胁，并相应进行处理。既包括在源代码层面对每个开发人员的源代码进行安全控制，也包括在架构层面对前端 Web 服务器的安全控制。
  • 对系统进行监控，制定异常处理预案。
  • 在开发环境和持续集成环境中使用漏洞扫描程序对代码、镜像、依赖进行扫描。
  • 对开发人员、架构师等开展安全培训，并在团队中配备一名安全人员。

  感谢原作者的翻译授权。如果你看到最后一定是收获颇丰，这里还有一个收获更多知识的方法，但比读完这篇文章要难得多，加入我们一起变强！

  变强之路充满荆棘，所以强者才受人尊敬