Access-Control-Allow-Methods: GET28、合理使用WebSockets，避免防跨站请求伪造等漏洞
到目前为止，WebSockets 仍然是一项相对较新的技术，在技术文档较少的情况下使用它不可避免地会有些风险。因此，在采用时一定要做到以下几点：
HSTS 也会影响 WebSockets，它会自动将未加密的 WebSocket 连接升级为 wss:// 如果您想要双重安全，您可以使用防跨站点请求伪造令牌作为 URL 参数。但是你需要为每个任务创建一个一次性的独立令牌，而不是直接使用防跨站请求伪造令牌，因为后者主要用于为应用程序的其他部分提供安全性。29、使用U2F令牌或客户端证书保护系统关键用户免受钓鱼攻击
如果系统可能面临网络钓鱼攻击的风险，比如说，“如果攻击者有可能创建一个虚假网站来欺骗管理员/首席执行官或其他用户信任、窃取他们的用户名、密码和验证码”，那么应该使用 U2F 令牌或客户端证书来防止这种攻击，这样即使有用户名、密码和验证码的攻击者也无法成功。
注意：强调钓鱼防护往往会给普通用户带来不必要的麻烦。但是，拥有更多选择对最终用户来说并不是一件坏事。此外，需要提前告知用户网络钓鱼攻击的危险性。30、防止跨站泄露
跨站泄露是一系列浏览器侧信道攻击。这种攻击允许恶意网站从其他 Web 应用程序的用户那里推断信息。
这种类型的攻击已经存在了一段时间，但浏览器最近才开始添加有针对性的预防机制。有关此类攻击的更多详细信息以及您应采取的安全控制措施，请参阅本文。
二、服务器端威胁防御
其次，是服务器端的威胁防御。在此，从应用系统、基础设施、应用架构、应用监控、事件响应等不同方面，总结如下建议：
2.1 应用系统31、 验证用户输入的有效性
此类措施最关键的方面之一是尽可能严格地验证所有用户输入。适当的验证可以使系统漏洞更难被发现和利用。只需拒绝无效的用户输入而不尝试对其进行清理。验证方面包括以下内容：
32、优雅的异常处理，避免技术细节泄露
不要向最终用户显示堆栈日志记录或类似的调试信息。使用全局异常处理程序来处理异常并向浏览器显示简单的错误消息。这使得攻击者更难发现和利用系统中的漏洞。
33、不要验证自己
对用户进行身份验证时可能会出现各种问题：防御密码猜测攻击、用户枚举攻击、管理密码重置和存储用户凭据。密码处理这么复杂，我们普通人不应该尝试。
直接使用auth0等类似工具进行认证，并使用一些广泛使用且安全的软件模块来实现通信协议（常见的是OpenID connect）。如果不想使用 auth0 等第三方身份提供者，也可以构建 KeyCloak 之类的服务。
34、验证一切以减少攻击面
应用系统默认应该对所有内容进行认证，除了一些静态资源、异常页面或注销页面。
35、多因素认证
如果有人入侵了身份验证服务怎么办？如果有这样的顾虑，直接去多因素认证（亲口说：除了密码，还需要手机验证码）。这样，即使身份认证服务被黑，攻击者可以冒充任何人，仍然无法知道手机收到的验证码。
36、通过严格的权限控制，避免未经授权的访问数据或功能
虽然权限控制不是一件容易的事，但也有一些方法可以妥善处理：只要永远记住不要忘记在控制器方法中验证用户权限，这会导致用户未经授权的漏洞，包括：
为了进一步明确权限管理工具，这里有一些要点：
37、使用适当的工具和技术来避免注入漏洞
注入漏洞的种类很多，而且都大同小异，包括SQL注入、HTML注入、XML注入、XPath注入、命令注入、SMTP注入、响应头注入等等。名称不同但本质相同，对应的解决方案也类似：
我不会在这里详细介绍，请记住：无论您是什么协议，请记住以上内容。后面会列出一些常见的注入漏洞。
38、创建安全的数据库查询语句，避免SQL注入漏洞
如果您想避免 SQL 注入漏洞已阻止此网站显示有安全证书错误的内容，请记住不要自己将 SQL 查询与字符串连接起来。实施对象关系映射框架 (ORM) 可以使开发更高效，应用程序更安全。
如果要构建更细粒度的查询，可以使用较低级别的 ORM。
如果您不能使用 ORM，请尝试准备好的语句，但也要注意此类语句比 ORM 更容易出错。
警告：
ORM框架不是万能的，体现在两个方面：一是仍然支持原生SQL查询，最好不要使用这样的查询；其次，像任何其他软件一样，ORM 框架也会时不时地暴露出来。. 因此，请坚持我们一再强调的策略：验证所有输入，使用 Web 应用程序防火墙 (WAF)，并保持包更新，这样您就可以高枕无忧了。39、谨慎使用操作系统命令行，防止命令注入相关漏洞
如果可以避免，最好不要执行操作系统命令。如果无法避免，最好遵循以下准则：
40、合理配置XML解析器，避免XML漏洞
作为一种标记语言，XML 是危险的，因为它可以访问系统资源。XSLT 的一些实现甚至支持嵌入式代码。因此，必须非常小心地处理它。
41、使用合适的类来构造URL，避免URL注入漏洞
URL注入经常发生在以下几种情况：
flavour = request.getParam("flavour");
url = "https:/api.local/pizzas/" + flavour + "/";
return get(url).json();如果风味设置为：
../admin/all-the-sensitive-things/那么这个API请求就变成了，是不是很危险？
解决的办法还是使用合适的URL构建库为URL传递参数，这样参数才能正确编码。
42、使用合适的类构建路径，避免路径遍历漏洞
就像使用 URL 地址一样，如果攻击者设法在路径中的某处偷偷摸摸 ../../../，文件路径最终可能会指向一个意外的位置。为避免这种情况，请创建一个安全构造路径的类并验证最终路径是否在预期目录中。避免文件路径中的不受信任的数据，或者更好的是，完全避免文件系统并直接进入云存储。
43、谨慎使用文件系统并接受不受信任的内容
如果允许用户写入服务器的文件系统，可能会出现各种问题。请改用云存储，或在数据库中使用二进制 blob。
如果您必须访问磁盘，则应遵循以下准则：
44、不要动态执行代码，避免远程代码执行漏洞
不要使用 eval 或等效函数。寻找实现代码执行的替代方法。否则，不受信任的数据可能会进行可能在服务器上执行恶意代码的函数调用。
45、合理使用序列化，避免反序列化漏洞
反序列化不受信任的数据是危险的，很容易导致远程代码执行。
2.2 基础架构 46、使用 Web 应用程序防火墙 (WAF)
安装防火墙会降低很多风险。ModSecurity 是一个不错的开源选择。
47、配置web服务器避免HTTP异步攻击
HTTP 不同步，也称为 HTTP 请求走私攻击，是攻击者劫持随机用户向系统发送的 HTTP 请求。此类攻击一般发生在以下几种情况：
那么如何预防呢？一般来说，根据使用的产品：
48、使用容器
让目标应用程序与其他应用程序隔离运行。这样，即使发生攻击，攻击者也无权访问未经授权的文件、系统或网络资源。因此，最好使用 Kubernetes 或云环境来部署您的应用程序。如果由于某种原因必须使用服务器，则可以手动使用 Docker 来约束应用程序。
49、使用 SELinux/AppArmor
即使应用程序通过容器运行，仍然需要 SELinux 或 AppArmor 策略来进一步约束应用程序，从而减少容器漏洞带来的威胁。
50、使用最低权限的服务帐户
这种方法的优点是即使发生攻击事件，也可以减少攻击造成的损失。同样，不可能列出所有情况，这里仅举几个例子来帮助您理解：
51、限制外网连接
攻击者通常需要建立一定的反向通信通道来建立操纵通道或窃取数据。此外，某些漏洞需要外部网络连接才能被发现和利用。
因此，不能让应用随便访问外部网络，包括DNS。尝试在服务器上运行命令nslookup，如果运行成功，说明你对外网连接没有适当的限制。如何处理此类问题通常取决于基础设施。
对于外部 TCP/UDP/ICMP 连接，一般可以通过以下方式禁用：
DNS 处理起来有点棘手，我们通常需要允许访问某些主机。
52、跟踪DNS记录以防止子域劫持
子域劫持场景示例如下：
如果我们拥有一个域名；
为了促销，我们购买了另一个域名 my-cool-campaign.com 并从 my-cool-campaign.com 创建了一个别名映射；
此次促销后，my-cool-campaign.com 域名也过期了；
但是，从到 my-cool-campaign.com 的别名映射仍然存在；
如果有人购买了过期域名，可以直接指向域名；
如果攻击者在域名my-cool-campaign.com下提供一些恶意内容，可以直接通过域名访问；
因此，请密切注意您的 DNS 记录。如果有很多类似的情况需要处理，强烈建议您做一个自动监控的解决方案。
2.3 架构53、创建内部API来访问数据源
您不应该对联网的网络应用程序过于信任。例如，不应允许建立数据库直接连接。否则，当有人破坏应用程序时，整个数据库都将处于危险之中。
相反，我们应该构建一个多组件架构，例如：
如果黑客现在想闯入我们的应用程序，即使成功了，他也没有访问整个数据库的权限，而只是使用用户的令牌来访问令牌允许访问的部分数据。
54、内部连接也被加密和认证
不要盲目相信内网的安全，破解的方法有很多。对于系统之间的访问，使用TLS（即HTTPS）进行加密，最好在网络和系统级别对连接进行认证。
55、敏感信息集中管理
如果没有适当的敏感信息管理方案，就很难保持授权的短暂性、可审计性和机密性。因此，建议使用 HashiCorp Vault 等工具来集中管理密码、加密密钥等。
2.4 监控56、收集、分析、报警
将日志集中收集到独立系统，例如 SIEM（安全信息和事件监控系统）。在这个系统中，当某些具有漏洞和攻击特征的事件发生时，可以发出警报。当发生严重威胁时，可以立即通知相关人员。
57、收集系统安全事件
可能最重要的日志来源是系统本身。当发生可疑行为时，系统应该能够引发异常、记录事件，并且如果可能的话，甚至自动阻止可能导致问题的用户或 IP 地址。常见的可疑行为包括：
58、 收集运行时安全日志
使用 Falco 等运行时安全监控工具检测异常系统访问。如果采用 Kubernetes，Falco 特别有用。还可以远程收集和监控日志。
59、收集 SELinux/AppArmor 日志
如果我们有阻止外部连接的 SELinux 策略，但系统突然向外部网站（例如 burpcollaborator.net）发起 HTTP 请求，则需要立即注意。或者您的系统正在尝试访问 /etc/passwd。在这两种情况下，都有人在我们的系统中发现了漏洞。
60、收集 Web 服务器事件
对于Web服务器软件，至少要收集访问日志和错误日志，然后发送到一个集中的日志服务器。这将有助于我们在响应事件时快速梳理时间线。
61、收集 Web 应用程序防火墙 (WAF) 日志
如果您按照上面的建议使用 Web 应用程序防火墙 (WAF)，请同时收集此日志。但是不要给这个日志设置警报，因为它基本上会收到来自互联网的各种问题，而不是一些你不必担心的问题。
2.5 事件响应 62、制定响应计划
一旦我们的系统被监控和加固，攻击者就很难快速定位系统漏洞，即使最终被发现，我们也可以快速了解情况。
但了解情况还不够。您还需要准备以下内容：
六、开发管理
63、威胁模型
系统地思考“可能出什么问题”并做出相应的调整。在设计新系统时，越早开始这一步越好。当对系统进行更改时，重新组织流程。
例如：
小王：如果攻击者入侵了我们的联网服务器怎么办？
小陈：到此为止！
小王：好的！这意味着我们这里有信任关系，我们相信连接到互联网的服务器不会被攻破。我们可以相信这个吗？
小陈：不一定！有一百种情况可能导致我们的服务器被黑客入侵，例如我们的代码中的漏洞、依赖项中的漏洞或安装在我们 Web 服务器上的软件中的漏洞。
小王：好的！所以让我们打破这种信任关系。接下来做什么？
小陈：让我们这样分解系统：创建一些内部接口来实际访问数据库，从那时起，前端Web服务器无法直接访问后端的所有内容。
小王：这是个好办法！除此之外，还有什么可能出错的？
小陈：那么，如果黑客入侵了我们的内网怎么办？
小王：那一切都会丢失已阻止此网站显示有安全证书错误的内容，因为内网服务器之间的连接是未加密的。
小陈：……
这就是威胁模型，不需要很复杂。使用此方法查找系统中可能存在的威胁。
64、强制源代码审查
通过技术控制手段，防止代码未经他人审核就提交给库。这是构建安全开发环境的基础，因为它可以：
如果攻击者破坏了开发者的计算机，或者开发者自己试图发起攻击，恶意代码无法直接移入代码库；
如果开发者的错误导致引入易受攻击的代码，很可能在被他人检查时被及时发现。
65、自动化持续集成流水线，只允许简单访问
开发者应该有触发 Jenkins 构建的权限，并且 Jenkins 权限只能这样配置，不允许其他权限。单个开发人员不应该能够在构建阶段引入任意代码。当然，如果上面推荐的代码审查是强制性的，Jenkinsfile 也可以保存在版本管理工具中。
66、签署工件
如果您正在构建容器镜像，您可以将镜像作为构建的一部分进行签名。将签名密钥存储在安全的地方。构建阶段需要访问密钥，但请避免将密钥与 Jenkinsfile 一起存储在版本管理工具中。更好的方法是将密钥存储在 HashiCorp Vault 之类的东西中，然后在构建时提取。
67、在持续集成管道中添加静态应用扫描器
在持续集成管道中使用 SpotBugs 和 Find-Sec-Bugs 等工具（或根据您使用的技术堆栈进行选择）。它们可以帮助您在部署代码之前找到已知漏洞。
或者，它可以作为 IDE 插件安装在开发人员的计算机上，以在代码移入之前运行这些工具进行检查。
68、在构建时检查依赖项以确保最小的依赖项集
应用程序所依赖的每个包都是风险来源。通过依赖，我们拉取第三方代码并在我们的应用服务器上执行，所以我们必须弄清楚我们所依赖的这个包是什么，为什么要依赖它？
保持最小的依赖集；
仅使用我们信任的依赖项。它们必须被广泛使用并广为人知；
使用构建框架来验证依赖关系。
此外，严格控制应用服务器的外部连接，避免后门的存在。
69、依赖的安全扫描
使用 OWASP Dependency Checker 扫描依赖项以查找常见的安全问题。除了处于持续集成管道中之外，还可以在开发人员的开发环境中运行这些工具。
70、持续集成管道对图像执行安全扫描
如果使用容器化技术，可以使用 Trivy 等工具对容器镜像进行一些通用漏洞扫描。
71、自动化部署和签名验证
开发者可以拥有部署到生产环境的权限，但是权限的范围应该控制之前阶段已经构建和签名的特定镜像，而不是直接访问生产服务器。如果您使用的是 Kubernetes，您可以通过 Notary 或 Open Policy Agent 验证要部署的镜像的签名。
72、设置保安员
一个人的精力是有限的。我们不能期望每个开发人员都精通渗透测试或安全工程师。正如您不能期望所有安全专家都是优秀的开发人员一样。因此，可以在团队中有专门的安全专职人员，主要是与开发人员、架构师沟通，帮助保护我们的应用程序，并在团队中传播安全意识。
三、结论
为了确保应用程序的安全，仅仅避免漏洞是不够的。必须综合考虑，主动防御。这里总结了一些主要的方法：
如果你看到最后一定很有收获，这里有另一种获取更多知识的方法，但比阅读这篇文章要难得多，加入我们变得更强大吧！
成为强者的道路充满荆棘，所以强者受到尊重
