0x00 前言

OWASP（开放式Web应用程序安全项目）的工具、文档、论坛和全球各地分会都是开放的，对所有致力于改进应用程序安全的人士开放，其最具权威的就是“10项最严重的Web 应用程序安全风险列表” ，总结了Web应用程序最可能、最常见、最危险的十大漏洞，是开发、测试、服务、咨询人员应知应会的知识。

A1:2017-注入

将不受信任的数据作为命令或查询的一部分发送到解析器时，会产生诸如SQL注入、NoSQL注入、OS注入和LDAP注入的注入缺陷。攻击者的恶意数据可以诱使解析器在没有适当授权的情况下执行非预期命令或访问数据。 

如何防止？

• 防止注入漏洞需要将数据与命令语句、查询语句分隔开来。
• 最佳选择是使用安全的API，完全避免使用解释器，或提供参数
化界面的接口，或迁移到ORM或实体框架。
• 注意：当参数化时，存储过程仍然可以引入SQL注入，如果
PL/SQL或T-SQL将查询和数据连接在一起，或者执行带有立即
执行或exec()的恶意数据。
• 使用正确的或“白名单”的具有恰当规范化的输入验证方法同样
会有助于防止注入攻击，但这不是一个完整的防御，因为许多应
用程序在输入中需要特殊字符，例如文本区域或移动应用程序的
API。 • 对于任何剩余的动态查询，可以使用该解释器的特定转义语法转
义特殊字符。OWASP的Java Encoder和类似的库提供了这样的
转义例程。
• 注意：SQL结构，比如：表名、列名等无法转义，因此用户提供
的结构名是非常危险的。这是编写软件中的一个常见问题。
• 在查询中使用LIMIT和其他SQL控件，以防止在SQL注入时大量
地泄露记录。

A2:2017-失效的身份认证

通过错误使用应用程序的身份认证和会话管理功能，攻击者能够破译密码、密钥或会话令牌，或者暂时或永久的冒充其他用户的身份。

凭证填充
已知密码

如何防止？

• 在可能的情况下，实现多因素身份验证，以防止自动、凭证填充、
暴力破解和被盗凭据再利用攻击。
• 不要使用发送或部署默认的凭证，特别是管理员用户。
• 执行弱密码检查，例如测试新或变更的密码，以纠正“排名前
10000个弱密码” 列表。
• 将密码长度、复杂性和循环策略与NIST-800-63 B的指导方针的
5.1.1章节-记住秘密，或其他现代的基于证据的密码策略相一致。
• 确认注册、凭据恢复和API路径，通过对所有输出结果使用相同
的消息，用以抵御账户枚举攻击。
• 限制或逐渐延迟失败的登录尝试。记录所有失败信息并在凭据填
充、暴力破解或其他攻击被检测时提醒管理员。
• 使用服务器端安全的内置会话管理器，在登录后生成高度复杂的
新随机会话ID。会话ID不能在URL中，可以安全地存储和当登出、
闲置、绝对超时后使其失效。

A3:2017-敏感数据泄露

这个比较好理解，一般我们的敏感信息包括密码、财务数据、医疗数据等，由于web应用或者API未加密或不正确的保护敏感数据，这些数据极易遭到攻击者利用，攻击者可能使用这些数据来进行一些犯罪行为，因此，未加密的信息极易遭到破坏和利用，我们应该加强对敏感数据的保护，web应用应该在传输过程中数据、存储的数据以及和浏览器的交互时的数据进行加密，保证数据安全。

如何防止？

对一些需要加密的敏感数据，应该起码做到以下几点：
• 对系统处理、存储或传输的数据分类，并根据分类进行访问控制。
• 熟悉与敏感数据保护相关的法律和条例，并根据每项法规要求保
护敏感数据。
• 对于没必要存放的、重要的敏感数据，应当尽快清除，或者通过
PCI DSS标记或拦截。未存储的数据不能被窃取。
• 确保存储的所有敏感数据被加密。
• 确保使用了最新的、强大的标准算法或密码、参数、协议和密匙，
并且密钥管理到位。
• 确保传输过程中的数据被加密，如：使用TLS。确保数据加密被
强制执行，如：使用HTTP严格安全传输协议（HSTS ）。
• 禁止缓存对包含敏感数据的响应。
• 确保使用密码专用算法存储密码，如：Argon2 、 scrypt 、
bcrypt 或者PBKDF2 。将工作因素（延迟因素）设置在可接受
范围。
• 单独验证每个安全配置项的有效性。

A4:2017-外部实体(XXE)

XXE 全称为XML External Entity attack 即XML(可扩展标记语言) 外部实体注入攻击，早期或配置错误的XML处理器评估了XML文件外部实体引用，攻击者可以利用这个漏洞窃取URI(统一资源标识符)文件处理器的内部文件和共享文件、监听内部扫描端口、执行远程代码和实施拒绝服务攻击。

如何防止？

开发人员培训是识别和减少XXE缺陷的关键，此外，防止XXE 缺
陷还需要：
• 尽可能使用简单的数据格式（如：JSON），避免对敏感数据进
行序列化。
• 及时修复或更新应用程序或底层操作系统使用的所有XML处理器
和库。同时，通过依赖项检测，将SOAP更新到1.2版本或更高
版本。
• 参考《 OWASP Cheat Sheet ‘XXE Prevention‘ 》，在应用程序
的所有XML解析器中禁用XML外部实体和DTD进程。
• 在服务器端实施积极的（“白名单”）输入验证、过滤和清理，
以防止在XML文档、标题或节点中出现恶意数据。
• 验证XML或XSL文件上传功能是否使用XSD验证或其他类似验证
方法来验证上传的XML文件。
• 尽管在许多集成环境中，手动代码审查是大型、复杂应用程序的
最佳选择，但是SAST 工具可以检测源代码中的XXE漏洞。
如果无法实现这些控制，请考虑使用虚拟修复程序、API安全网关
或Web应用程序防火墙（ WAF ）来检测、监控和防止XXE攻
击。

A5:2017-失效的访问控制

通过身份验证的用户，可以访问其他用户的相关信息，没有实施恰当的访问权限。攻击者可以利用这个漏洞去查看未授权的功能和数据，eg:访问用户的账户、敏感文件、获取和正常用户相同的权限等.

如何防止？

访问控制只有在受信服务器端代码或没有服务器的 API 中有效，
这样这样攻击者才无法修改访问控制检查或元数据。
• 除公有资源外，默认情况下拒绝访问。
• 使用一次性的访问控制机制，并在整个应用程序中不断重用它们，
包括最小化CORS使用。
• 建立访问控制模型以强制执行所有权记录，而不是接受用户创建、
读取、更新或删除的任何记录。
• 域访问控制对每个应用程序都是唯一的，但业务限制要求应由域
模型强制执行。
• 禁用 Web服务器目录列表，并确保文件元数据（如：git）不存
在于 Web的根目录中。
• 记录失败的访问控制，并在适当时向管理员告警（如：重复故
障）。
• 对API和控制器的访问进行速率限制，以最大限度地降低自动化
攻击工具的危害。
• 当用户注销后，服务器上的JWT令牌应失效。

A6:2017-安全配置错误

安全配置错误是比较常见的漏洞，由于操作者的不当配置(默认配置，临时配置，开源云存储，http标头配置，以及包含敏感信息的详细错误)，导致攻击者可以利用这些配置获取到更高的权限，安全配置错误可以发生在各个层面，包含平台、web服务器、应用服务器、数据库、架构和代码。

如何防止？

应实施安全的安装过程，包括：
• 一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。
开发、质量保证和生产环境都应该进行相同配置，并且，在每个
环境中使用不同的密码。这个过程应该是自动化的，以尽量减少
安装一个新安全环境的耗费。
• 搭建最小化平台，该平台不包含任何不必要的功能、组件、文档
和示例。移除或不安装不适用的功能和框架。
• 检查和修复安全配置项来适应最新的安全说明、更新和补丁，并
将其作为更新管理过程的一部分，（参见A9：2017-使用含有已
知漏洞的组件）。在检查过程中，应特别注意云存储权限（如：
S3桶权限）。
• 一个能在组件和用户间提供有效的分离和安全性的分段应用程
序架构，包括：分段、容器化和云安全组。
• 向客户端发送安全指令，如：安全标头。 • 在所有环境中能够进行正确安全配置和设置的自动化过程。

A7:2017-跨站脚本（xss）

xss攻击全称为跨站脚本攻击,当应用程序的新网页中包含不受信任的、未经恰当验证、转义的数据或可以使用HTML、JavaScript的浏览器API更新的现有网页时，就会出现xss漏洞，跨站脚本攻击是最普遍的web应用安全漏洞，甚至在某些安全平台都存在xss漏洞。xss会执行攻击者在浏览器中执行的脚本，并劫持用户会话，破坏网站或用户重定向到恶意站点，使用xss还可以执行拒绝服务攻击。

如何防止？

防止XSS需要将不可信数据与动态的浏览器内容区分开。这可以
通过如下步骤实现：
• 使用设计上就会自动编码来解决XSS问题的框架，如：Ruby 3.0 
或 React JS。了解每个框架的XSS保护的局限性，并适当地处
理未覆盖的用例。
• 为了避免反射式或存储式的XSS漏洞，最好的办法是根据HTML
输出的上下文（包括：主体、属性、JavaScript、CSS或URL）
对所有不可信的HTTP请求数据进行恰当的转义 。更多关于数据
转义技术的信息见：《OWASP Cheat Sheet ‘XSS Prevention’》 。• 在客户端修改浏览器文档时，为了避免DOM XSS攻击，最好的
选择是实施上下文敏感数据编码。如果这种情况不能避免，可以
采用《OWASP Cheat Sheet ‘DOM based XSS Prevention ‘》
描述的类似上下文敏感的转义技术应用于浏览器API。 • 使用内容安全策略（CSP）是对抗XSS的深度防御策略。如果
不存在可以通过本地文件放置恶意代码的其他漏洞（例如：路径
遍历覆盖和允许在网络中传输的易受攻击的库），则该策略是有
效的。

A8:2017-不安全的反序列化

不安全的反序列化可以导致远程代码执行、重放攻击、注入攻击或特权升级攻击

如何防止？

唯一安全的架构模式是不接受来自不受信源的序列化对象，或使
用只允许原始数据类型的序列化媒体。
如果上述不可能的话，考虑使用下述方法：
• 执行完整性检查，如：任何序列化对象的数字签名，以防止恶
意对象创建或数据篡改。
• 在创建对象之前强制执行严格的类型约束，因为代码通常被期
望成一组可定义的类。绕过这种技术的方法已经被证明，所以
完全依赖于它是不可取的。
• 如果可能，隔离运行那些在低特权环境中反序列化的代码。
• 记录反序列化的例外情况和失败信息，如：传入的类型不是预
期的类型，或者反序列处理引发的例外情况。
• 限制或监视来自于容器或服务器传入和传出的反序列化网络连
接。
• 监控反序列化，当用户持续进行反序列化时，对用户进行警告。

A9:2017-使用含有已知漏洞的组件

组件(eg：库、框架或其他软件模块)拥有应用程序相同的权限，如果应用程序中含有已知漏洞，攻击者可以利用漏洞获取数据或接管服务器。同时，使用这些组件会破坏应用程序防御，造成各种攻击产生严重的后果。

如何防止？

应该制定一个补丁管理流程：
• 移除不使用的依赖、不需要的功能、组件、文件和文档。
• 利用如 versions、DependencyCheck 、retire.js等工具来持续的
记录客户端和服务器端以及它们的依赖库的版本信息。持续监控
如CVE 和 NVD等是否发布已使用组件的漏洞信息，可以使用软
件分析工具来自动完成此功能。订阅关于使用组件安全漏洞的警
告邮件。
• 仅从官方渠道安全的获取组件，并使用签名机制来降低组件被篡
改或加入恶意漏洞的风险
• 监控那些不再维护或者不发布安全补丁的库和组件。如果不能打
补丁，可以考虑部署虚拟补丁来监控、检测或保护。
每个组织都应该制定相应的计划，对整个软件生命周期进行监控、
评审、升级或更改配置。

A10:2017-不足的日志记录和监控

不足的日志记录和监控，以及事件响应缺失或无效的集成，使攻击者能够进一步攻击系统、保持持续性的或攻击更多的系统，以及对数据的不当操作。

如何防止？

根据应用程序存储或处理的数据的风险：: • 确保所有登录、访问控制失败、输入验证失败能够被记录到日
志中去，并保留足够的用户上下文信息，以识别可疑或恶意帐
户，并为后期取证预留足够时间。
• 确保日志以一种能被集中日志管理解决方案使用的形式生成
• 确保高额交易有完整性控制的审计信息，以防止篡改或删除，
例如审计信息保存在只能进行记录增加的数据库表中。
• 建立有效的监控和告警机制，使可疑活动在可接受的时间内被
发现和应对。
• 建立或采取一个应急响应机制和恢复计划，例如：NIST 800-
61 rev 2或更新版本。

参考链接