解读OWASP TOP 10

## **TOP 1** 注入

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

几乎任何数据源都能成为注入载体，包括环境变量、所有类型的用户、参数、外部和内部web服务。当攻击者可以向解释器发送恶意数据时，注入漏洞产生。

注入漏洞十分普遍，尤其是在遗留代码中。注入漏洞通常能在SQL、LDAP、XPath或是NoSQL查询语句、OS命令、XML解析器、SMTP包头、表达式语句及ORM查询语句中找到。

注入漏洞很容易通过代码审查发现。扫描器和模糊测试工具可以帮助攻击者找到这些漏洞。

**危害**

注入能导致数据丢失、破坏或泄露给无授权方，缺乏可审计性或是拒绝服务。注入有时甚至能导致主机完全被接管。

**危险点**

1. 用户提供的数据没有经过应用程序的验证、过滤或净化

2. 动态查询语句或非参数化的调用，在没有上下文感知转义的情况下，被用于解释器。

3. 在ORM搜索参数中使用了恶意数据，这样搜索就获得包含敏感或未授权的数据。

4. 恶意数据直接被使用或连接，诸如SQL语句或命令在动态查询语句、命令或存储过程中包含结构和恶意数据。

**防御方法**

一些常见的注入，包括：SQL、OS命令、ORM、LDAP和表达式语言（EL）或OGNL注入。所有解释器的概念都是相同的。代码评审是最有效的检测应用程序的注入风险的办法之一，紧随其后的是对所有参数、字段、头、cookie、JSON和XML数据输入的彻底的DAST扫描。

1. 最佳选择是使用安全的API，完全避免使用解释器，或提供参数化界面的接口，或迁移到ORM或实体框架。注意：当参数化时，存储过程仍然可以引入SQL注入，如果PL/SQL或T-SQL将查询和数据连接在一起，或者执行带有立即执行或exec()的恶意数据。

2. 使用正确的或“白名单”的具有恰当规范化的输入验证方法同样会有助于防止注入攻击，但这不是一个完整的防御，因为许多应用程序在输入中需要特殊字符，例如文本区域或移动应用程序的API。

3. 对于任何剩余的动态查询，可以使用该解释器的特定转义语法转义特殊字符。OWASP的Java Encoder和类似的库提供了这样的转义例程。注意：SQL结构，比如：表名、列名等无法转义，因此用户提供的结构名是非常危险的。这是编写软件中的一个常见问题。

4. 在查询中使用LIMIT和其他SQL控件，以防止在SQL注入时大量地泄露记录。

## TOP 2 失效的身份认证

**描述**

攻击者可以获得数百万的有效用户名和密码组合，包括证书填充、默认的管理帐户列表、自动的暴力破解和字典攻击工具，以及高级的GPU破解工具。会话管理攻击很容易被理解，尤其是没有过期的会话密匙。

**危害**

攻击者只需要访问几个帐户，或者只需要一个管理员帐户就可以破坏我们的系统。根据应用程序领域的不同，可能会导致放任洗钱、社会安全欺诈以及用户身份盗窃、泄露法律高度保护的敏感信息。

**危险点**

1. 允许凭证填充，这使得攻击者获得有效用户名和密码的列表。

2. 允许暴力破解或其他自动攻击。

3. 允许默认的、弱的或众所周知的密码，例如“Password1”或“admin/admin”。

4. 使用弱的或失效的验证凭证，忘记密码程序，例如“基于知识的答案”，这是不安全的。

5. 使用明文、加密或弱散列密码。

6. 缺少或失效的多因素身份验证。

7. 暴露URL中的会话ID（例如URL重写）。

8. 在成功登录后不会更新会话ID。

9. 不正确地使会话ID失效。当用户不活跃的时候，用户会话或认证令牌（特别是单点登录（SSO）令牌）没有正确注销或失效

**防御方法**

1. 在可能的情况下，实现多因素身份验证，以防止自动、凭证填充、暴力破解和被盗凭据再利用攻击。

2. 不要使用发送或部署默认的凭证，特别是管理员用户。

3. 执行弱密码检查，例如测试新或变更的密码，以纠正“排名前10000个弱密码” 列表。

4. 将密码长度、复杂性和循环策略与NIST-800-63 B的指导方针的

5. 5.1.1章节-记住秘密，或其他现代的基于证据的密码策略相一致。

6. 确认注册、凭据恢复和API路径，通过对所有输出结果使用相同的消息，用以抵御账户枚举攻击。

7. 限制或逐渐延迟失败的登录尝试。记录所有失败信息并在凭据填充、暴力破解或其他攻击被检测时提醒管理员。

8. 使用服务器端安全的内置会话管理器，在登录后生成高度复杂的新随机会话ID。会话ID不能在URL中，可以安全地存储和当登出、闲置、绝对超时后使其失效。

## TOP3 敏感数据泄露

**描述**

攻击者不是直接攻击密码，而是在传输过程中或从客户端（例如：浏览器）窃取密钥、发起中间人攻击，或从服务器端窃取明文数据。这通常需要手动攻击。通过使用图形处理单元（GPU），早前检索的密码数据库可能被暴力破解。

**危险点**

1. 在数据传输过程中是否使用明文传输？这和传输协议相关，如：HTTP、SMTP和FTP。外部网络流量非常危险。验证所有的内部通信，如：负载平衡器、Web服务器或后端系统之间的通信。

2. 当数据被长期存储时，无论存储在哪里，它们是否都被加密，包含备份数据？

3. 无论默认条件还是源代码中，是否还在使用任何旧的或脆弱的加密算法？

4. 是否使用默认加密密钥，生成或重复使用脆弱的加密密钥，或者缺少恰当的密钥管理或密钥回转？

5. 是否强制加密敏感数据，例如：用户代理（如：浏览器）指令和传输协议是否被加密？

6. 用户代理（如：应用程序、邮件客户端）是否未验证服务器端证书的有效性？

## TOP4 XML外部实体（XXE）

**描述**

如果攻击者可以上传XML文档或者在XML文档中添加恶意内容，通过易受攻击的代码、依赖项或集成，他们就能够攻击含有缺陷的XML处理器。

默认情况下，许多旧的XML处理器能够对外部实体、XML进程中被引用和评估的URI进行规范。

**危害**

XXE缺陷可用于提取数据、执行远程服务器请求、扫描内部系统、执行拒绝服务攻击和其他攻击。业务影响取决于所有受影响的应用程序和数据保护需求

**危险点**

1. 应用程序直接接受XML文件或者接受XML文件上传，特别是来自不受信任源的文件，或者将不受信任的数据插入XML文件，并提交给XML处理器解析。

2. 在应用程序或基于Web服务的SOAP中，所有XML处理器都启用了文档类型定义（DTDs）。因为禁用DTD进程的确切机制因处理器而不同，

3. 如果为了实现安全性或单点登录（SSO），应用程序使用SAML进行身份认证。而SAML使用XML进行身份确认，那么应用程序就容易受到XXE攻击。

4. 如果应用程序使用第1.2版之前的SOAP，并将XML实体传递到SOAP框架，那么它可能受到XXE攻击。

5. 存在XXE缺陷的应用程序更容易受到拒绝服务攻击，包括：Billion Laughs 攻击

**防御方法**

1. 尽可能使用简单的数据格式（如：JSON），避免对敏感数据进行序列化。

2. 及时修复或更新应用程序或底层操作系统使用的所有XML处理器和库。同时，通过依赖项检测，将SOAP更新到1.2版本或更高版本。

3. 参考《 OWASP Cheat Sheet ‘XXE Prevention‘ 》，在应用程序的所有XML解析器中禁用XML外部实体和DTD进程。

4. 在服务器端实施积极的（“白名单”）输入验证、过滤和清理，以防止在XML文档、标题或节点中出现恶意数据。

5. 验证XML或XSL文件上传功能是否使用XSD验证或其他类似验证方法来验证上传的XML文件。

6. 尽管在许多集成环境中，手动代码审查是大型、复杂应用程序的最佳选择，但是SAST 工具可以检测源代码中的XXE漏洞。

7. 如果无法实现这些控制，请考虑使用虚拟修复程序、API安全网关或Web应用程序防火墙（ WAF ）来检测、监控和防止XXE攻击

## TOP5 失效的访问控制

**描述**

由于缺乏自动化的检测和应用程序开发人员缺乏有效的功能测试，因而访问控制缺陷很常见。访问控制检测通常不适用于自动化的静态或动态测试。手动测试是检测访问控制缺失或失效的最佳方法，包

括：HTTP方法（如：GET和PUT）、控制器、直接对象引用等

**危害**

技术影响是攻击者可以冒充用户、管理员或拥有特权的用户，或者创建、访问、更新或删除任何记录。

业务影响取决于应用程序和数据的保护需求。

**危险点**

常见的访问控制脆弱点包括：

1. 通过修改 URL、内部应用程序状态或 HTML 页面绕过访问控制检查，或简单地使用自定义的 API 攻击工具。

2. 允许将主键更改为其他用户的记录，例如查看或编辑他人的帐户。

3. 特权提升。在不登录的情况下假扮用户，或以用户身份登录时充当管理员。

4. 元数据操作，如重放或篡改 JWT 访问控制令牌，或作以提升权限的cookie 或隐藏字段。

5. CORS配置错误允许未授权的API访问。

6. 以未通过身份验证的用户身份强制浏览的通过身份验证时才能看到的页面、或作为标准用户访问具有相关权限的页面、或API没有对POST、PUT和DELETE强制执行访问控制

**防御点**

1. 除公有资源外，默认情况下拒绝访问。

2. 使用一次性的访问控制机制，并在整个应用程序中不断重用它们，包括最小化CORS使用。

3. 建立访问控制模型以强制执行所有权记录，而不是接受用户创建、读取、更新或删除的任何记录。

4. 域访问控制对每个应用程序都是唯一的，但业务限制要求应由域模型强制执行。

5. 禁用 Web服务器目录列表，并确保文件元数据（如：git）不存在于 Web的根目录中。

6. 记录失败的访问控制，并在适当时向管理员告警（如：重复故障）。

7. 对API和控制器的访问进行速率限制，以最大限度地降低自动化攻击工具的危害。

8. 当用户注销后，服务器上的JWT令牌应失效

## TOP6 安全配置错误

**描述**

认账户、不再使用的页面、未受保护的文件和目录等来取得对系统的未授权的访问或了解。

安全配置错误可以发生在一个应用程序堆栈的任何层面，包括网络服务、平台、Web服务器、应用服务器、数据库、框架、自定义代码和预安装的虚拟机、容器和存储。自动扫描器可用于检测错误的安全配置、默认帐户的使用或配置、不必要的服务、遗留选项等

**危害**

这些漏洞使攻击者能经常访问一些未授权的系统数据或功能。有时，这些漏洞导致系统的完全攻破。

业务影响取决于您的应用程序和数据的保护需求

**危险点**

1. 应用程序栈堆的任何部分都缺少适当的安全加固，或者云服务的权限配置错误。

2. 应用程序启用或安装了不必要的功能（例如：不必要的端口、服务、网页、帐户或权限）。

3. 默认帐户的密码仍然可用且没有更改。

4. 错误处理机制向用户披露堆栈跟踪或其他大量错误信息。

5. 对于更新的系统，禁用或不安全地配置最新的安全功能。

6. 应用程序服务器、应用程序框架（如：Struts、Spring、ASP.NET）、库文件、数据库等没有进行安全配置。

7. 服务器不发送安全标头或指令，或者未对服务器进行安全配置。

8. 应用软件已过期或易受攻击（参见A9：2017-使用含有已知漏洞的组件）。

9. 缺少一个体系的、可重复的应用程序安全配置过程，系统将处于高风险中

**防御方法**

1. 一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。开发、质量保证和生产环境都应该进行相同配置，并且，在每个环境中使用不同的密码。这个过程应该是自动化的，以尽量减少安装一个新安全环境的耗费。

2. 搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和示例。移除或不安装不适用的功能和框架。

3. 检查和修复安全配置项来适应最新的安全说明、更新和补丁，并将其作为更新管理过程的一部分，

4. 一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构，包括：分段、容器化和云安全组。

5. 向客户端发送安全指令，如：安全标头。

6. 在所有环境中能够进行正确安全配置和设置的自动化过程。

## TOP7 跨站脚本（XSS）

**三种类型：**

1. **反射式XSS**：应用程序或API包括未经验证和未经转义的用户输入，作为HTML输出的一部分。一个成功的攻击可以让攻击者在受害者的浏览器中执行任意的HTML和JavaScript。 通常，用户将需要与指向攻击者控制页面的某些恶意链接进行交互，例如恶意漏洞网站，广告或类似内容。

2. **存储式XSS**：你的应用或者API将未净化的用户输入存储下来了，并在后期在其他用户或者管理员的页面展示出来。 存储型XSS一般被认为是高危或严重的风险。

3. **基于DOM的XSS：**会动态的将攻击者可控的内容加入页面的JavaScript框架、单页面程序或API存在这种类型的漏洞。理想的来说，你应该避免将攻击者可控的数据发送给不安全的JavaScript API

**防御方法**

1. 使用设计上就会自动编码来解决XSS问题的框架，如：Ruby 3.0 或 React JS。了解每个框架的XSS保护的局限性，并适当地处理未覆盖的用例。

2. 为了避免反射式或存储式的XSS漏洞，最好的办法是根据HTML输出的上下文（包括：主体、属性、JavaScript、CSS或URL）对所有不可信的HTTP请求数据进行恰当的转义 。

3. 在客户端修改浏览器文档时，为了避免DOM XSS攻击，最好的选择是实施上下文敏感数据编码。如果这种情况不能避免，可以采用《OWASP Cheat Sheet ‘DOM based XSS Prevention ‘》描述的类似上下文敏感的转义技术应用于浏览器API。

4. 使用内容安全策略（CSP）是对抗XSS的深度防御策略。如果不存在可以通过本地文件放置恶意代码的其他漏洞（例如：路径遍历覆盖和允许在网络中传输的易受攻击的库），则该策略是有效的

## TOP8 不安全的反序列化

**描述**

这一问题包括在Top 10的行业调查中，而不是基于可量化的数据。

有些工具可以被用于发现反序列化缺陷，但经常需要人工帮助来验证发现的问题。对反序列化的利用是有点困难的。因为在不更改或调整底层可被利用代码的情况下，现成的反序列化漏洞很难被使用。

**应用：**

1. 远程和进程间通信（RPC / IPC）

2. 连线协议、Web服务、消息代理

3. 缓存/持久性

4. 数据库、缓存服务器、文件系统

5. HTTP cookie、HTML表单参数、API身份验证令牌

**危险点**

这可能导致两种主要类型的攻击：

1. 如果应用中存在可以在反序列化过程中或者之后被改变行为的类，则攻击者可以通过改变应用逻辑或者实现远程代码执行攻击。我们将其称为对象和数据结构攻击。

2. 典型的数据篡改攻击，如访问控制相关的攻击，其中使用了现有的数据结构，但内容发生了变化。

**防御方法**

1. 执行完整性检查，如：任何序列化对象的数字签名，以防止恶意对象创建或数据篡改。

2. 在创建对象之前强制执行严格的类型约束，因为代码通常被期望成一组可定义的类。绕过这种技术的方法已经被证明，所以完全依赖于它是不可取的。

3. 如果可能，隔离运行那些在低特权环境中反序列化的代码。

4. 记录反序列化的例外情况和失败信息，如：传入的类型不是预期的类型，或者反序列处理引发的例外情况。

5. 限制或监视来自于容器或服务器传入和传出的反序列化网络连接。

6. 监控反序列化，当用户持续进行反序列化时，对用户进行警告。

## TOP9 使用含有已知漏洞的组件

**描述**

**危险点**

1. 如果你不知道所有使用的组件版本信息（包括：服务端和客户端）。这包括了直接使用的组件或其依赖的组件。

2. 如果软件易受攻击，不再支持或者过时。这包括：OS、Web服务器、应用程序服务器、数据库管理系统（DBMS）、应用程序、API和所有的组件、运行环境和库。

3. 如果你不会定期做漏洞扫描和订阅你使用组件的安全公告。

4. 如果你不基于风险并及时修复或升级底层平台、框架和依赖库。很可能发生这种情况：根据变更控制，每月或每季度进行升级，这使得组织在这段时间内会受到已修复但未修补的漏洞的威胁。

5. 如果软件工程师没有对更新的、升级的或打过补丁的组件进行兼容性测试。

6. 如果你没有对组件进行安全配置（请参考“A6:2017-安全配置错误”）

**防御方法**

1. 移除不使用的依赖、不需要的功能、组件、文件和文档。

2. 利用如 versions、DependencyCheck 、retire.js等工具来持续的记录客户端和服务器端以及它们的依赖库的版本信息。持续监控如CVE 和 NVD等是否发布已使用组件的漏洞信息，可以使用软件分析工具来自动完成此功能。订阅关于使用组件安全漏洞的警告邮件。

3. 仅从官方渠道安全的获取组件，并使用签名机制来降低组件被篡改或加入恶意漏洞的风险

4. 监控那些不再维护或者不发布安全补丁的

库和组件。如果不能打补丁，可以考虑部署虚拟补丁来监控、检测或保护。

5. 每个组织都应该制定相应的计划，对整个软件生命周期进行监控、评审、升级或更改配置

## TOP10 不足的日志记录和监控

**描述**

判断你是否有足够监控的一个策略是在渗透测试后检查日志。 测试者的活动应被充分的记录下来，能够反映出他们造成了什么样的影响。

多数成功的攻击往往从漏洞探测开始。允许这种探测会将攻击成功的可能性提高到近100%。

**危险点**

1. 未记录可审计性事件，如：登录、登录失败和高额交易。

2. 告警和错误事件未能产生或产生不足的和不清晰的日志信息。

3. 没有利用应用系统和API的日志信息来监控可疑活动。

4. 日志信息仅在本地存储。

5. 没有定义合理的告警阈值和制定响应处理流程。

6. 渗透测试和使用DAST工具（如：OWASP ZAP）扫描没有触发告警

7. 对于实时或准实时的攻击，应用程序无法检测、处理和告警。

8. 如果应用日志信息或告警信息对用户或者攻击者可见，你就很容易遭受信息泄露攻击

**防御方法**

1. 确保所有登录、访问控制失败、输入验证失败能够被记录到日志中去，并保留足够的用户上下文信息，以识别可疑或恶意帐户，并为后期取证预留足够时间

2. 确保日志以一种能被集中日志管理解决方案使用的形式生成

3. 确保高额交易有完整性控制的审计信息，以防止篡改或删除，例如审计信息保存在只能进行记录增加的数据库表中。

4. 建立有效的监控和告警机制，使可疑活动在可接受的时间内被发现和应对。

5. 建立或采取一个应急响应机制和恢复计划。

6. 目前已有商业的和开源的应用程序防护框架（例如：OWASP AppSensor）、Web应用防火墙（例如 ：Modsecurity with the OWASP Core Rule Set）、带有自定义仪表盘和告警功能的日志