OWASP TOP 10 2021
OWASP TOP 10 2021
2021 年的 TOP 10 中有 3 个新类别、4 个更改了名称和范围的类别以及一些合并。
A01. 失效的访问控制 Broken Access Control
失效的访问控制是指应用程序中的访问控制措施没有被正确实施或没有被充分考虑，从而导致攻击者能够绕过访问控制措施，访问未授权的资源和执行未授权的操作。
具体来说，失效的访问控制漏洞可能包括以下方面：
- 目录遍历：攻击者可以通过修改URL或提交特定的请求参数来访问未授权的目录或文件。
- 权限提升：攻击者可以通过修改请求参数或通过其他方式来绕过应用程序的权限限制，从而获取更高的权限或执行未授权的操作。
- 会话劫持：攻击者可以通过获取或伪造合法用户的会话ID来伪装成合法用户，从而访问敏感资源或执行未授权的操作。
- 特权绕过：攻击者可以利用缺陷或漏洞绕过应用程序的特权限制，从而访问敏感资源或执行未授权的操作。
为了应对失效的访问控制漏洞，应用程序开发者和管理员可以采取以下措施：
- 实施强制访问控制：应用程序应该实现有效的访问控制策略，并防止攻击者通过伪造请求参数、修改URL或使用其他方法绕过访问控制。
- 实现最小化原则：应用程序应该仅授权所需最小限度的权限，并确保用户仅访问其需要的资源。
- 验证和授权：应用程序应该实现严格的身份验证和授权机制，以确保用户只能访问其授权的资源和操作。
- 实施会话管理：应用程序应该实施有效的会话管理机制，包括使用强密码、使用HTTPS协议、定期更新会话密钥等，以确保会话不被劫持或伪造。
- 进行安全测试：应用程序应该进行安全测试，包括漏洞扫描、渗透测试等，以识别潜在的失效的访问控制漏洞并及时修复。
A02. 加密机制失效 Cryptographic Failures
加密机制失效是指应用程序中使用的加密算法、密钥管理和其他相关技术存在漏洞或缺陷，导致加密机制无法达到预期的安全保护效果。
具体来说，加密机制失效可能包括以下方面：
- 弱加密算法：应用程序中使用的加密算法过于简单或易于被破解，从而导致加密数据不再安全。
- 不安全的密钥管理：应用程序中的密钥管理不够安全，如密钥存储在明文中、密钥强度不足等，使攻击者可以获取密钥并解密加密数据。
- 敏感信息泄露：敏感信息的传输或存储存在漏洞，如数据泄露、拦截、篡改等，使攻击者可以获取敏感数据。2017-A03 敏感信息泄露
- 暴力破解攻击：攻击者使用暴力破解等方法获取加密数据，从而导致加密机制失效。
为了应对加密机制失效漏洞，应用程序开发者和管理员可以采取以下措施：
- 选择强加密算法：应用程序应该选择强加密算法，并确保密钥的长度和强度足够安全。
- 实施安全的密钥管理：应用程序应该采用安全的密钥管理机制，包括密钥加密、密钥分发、密钥存储等，确保密钥不被泄露或破解。
- 实施安全的传输和存储：应用程序应该实施安全的传输和存储机制，包括使用SSL/TLS协议、加密传输、安全存储等，确保加密数据不被泄露或篡改。
- 防范暴力破解攻击：应用程序应该实施防范暴力破解攻击的措施，如限制登录尝试次数、使用复杂密码等，以防止攻击者通过暴力破解获取密钥或加密数据。
- 进行安全测试：应用程序应该进行安全测试，包括加密算法评估、密钥管理评估等，以识别潜在的加密机制失效漏洞并及时修复。
A03. 注入 Injection
注入漏洞是指攻击者可以通过注入恶意代码或指令来攻击应用程序的漏洞。常见的注入漏洞包括SQL注入、命令注入和LDAP注入等。
具体来说，注入漏洞可能包括以下方面：
- SQL注入：攻击者通过注入恶意的SQL代码来获取敏感数据、修改数据库内容或执行其他恶意操作。
- 命令注入：攻击者通过注入恶意的命令来执行系统命令、获取敏感信息或执行其他恶意操作。
- LDAP注入：攻击者通过注入恶意的LDAP代码来获取敏感数据、修改LDAP目录内容或执行其他恶意操作。
- 跨站脚本攻击（XSS）注入：攻击者通过在受害者浏览器中注入恶意脚本，从而获取用户的敏感信息，例如密码、银行账户等。XSS攻击可以分为反射型、存储型和DOM型三种类型。2017-A07 跨站脚本XSS
为了应对注入漏洞，应用程序开发者和管理员可以采取以下措施：
- 使用参数化查询：应用程序应该使用参数化查询或预处理语句，确保SQL语句的参数值是预先定义的，避免攻击者通过注入恶意的SQL代码来执行恶意操作。
- 过滤和验证输入：应用程序应该对用户输入进行过滤和验证，过滤特殊字符，限制特定的字符集,确保输入数据符合预期的格式和类型,避免攻击者通过注入恶意代码来执行恶意操作。在输出时使用HTML编码，避免JavaScript脚本注入。
- 最小化权限：应用程序应该最小化数据库用户的权限，避免攻击者通过注入恶意SQL代码来获取或修改敏感数据。
- 使用ORM框架：应用程序可以使用ORM框架（对象关系映射），ORM框架将处理SQL代码和参数传递，使开发人员可以避免手写的SQL代码中的注入问题。
- 检查系统日志：应用程序应该检查系统日志，监控攻击行为，及时发现和处理注入漏洞。
- 定期进行漏洞扫描：应用程序应该定期进行漏洞扫描，包括注入漏洞扫描，以及及时修复潜在的漏洞。
A04. 不安全设计 Insecure Design
不安全设计通常是由于设计不良或缺乏安全意识而导致的，攻击者可以利用这些设计缺陷来攻击应用程序。
具体来说，不安全设计可能包括以下方面：
- 未考虑安全性：开发人员在设计应用程序时没有考虑安全性，如忽略了访问控制、密码加密等。
- 信任过度：应用程序信任用户提供的数据，而不进行适当的验证，从而可能导致攻击者利用这些缺陷来攻击应用程序。
- 欺骗用户：应用程序会误导用户，让用户进行危险的操作，例如“记住我”功能可能导致用户在公共计算机上遭受攻击。
为了应对不安全设计，应用程序开发者和管理员可以采取以下措施：
- 实施安全性的开发生命周期：开发团队应该在整个应用程序开发过程中，重视安全性，包括设计、编码、测试和部署等。
- 审查设计和代码：开发人员应该审查设计和代码，以确保应用程序符合最佳安全实践，如采用强密码策略、安全的会话管理和访问控制等。
- 应用程序的最小权限：应用程序应该最小化用户权限，只授予必需的权限。
- 安全认证：应用程序应该对用户身份进行验证，并对敏感操作进行适当的认证和授权，避免攻击者利用应用程序中的信任问题来攻击。
- 针对安全性进行测试：应用程序应该定期进行安全性测试，包括代码审计、漏洞扫描和渗透测试等，以确保应用程序符合最佳安全实践，并及时修复发现的漏洞。
A05. 安全配置错误 Security Misconfiguration
安全配置错误通常是由于不正确的配置或管理而导致的，攻击者可以利用这些漏洞来攻击应用程序。
具体来说，安全配置错误可能包括以下方面：
- 默认密码：应用程序或其组件使用默认密码，攻击者可以轻松地利用这些密码访问应用程序或组件。
- 禁用安全功能：开发人员或管理员可能禁用了某些安全功能，例如文件上传的限制、错误消息的显示和日志记录等，从而导致应用程序易受攻击。
- 未正确配置XML解析器：XML外部实体攻击（XML External Entity, XXE）通常发生在应用程序未能正确配置XML解析器的情况下，攻击者利用了XML解析器处理外部实体的机制。当XML解析器解析XML文档时，它会根据定义在文档中的实体声明解析实体。攻击者可以通过定义恶意的外部实体并将其插入XML文档中，从而导致XML解析器执行恶意操作，例如读取文件、执行系统命令等等。2017-A04XML外部实体攻击(XXE)
- 不安全的默认配置：应用程序或其组件可能包含不安全的默认配置，例如开放的端口、调试模式、开放的文件共享等。
- 不及时的安全更新：应用程序或其组件可能包含已知的安全漏洞，但由于管理员没有及时更新，导致攻击者可以利用这些漏洞来攻击应用程序。
为了应对安全配置错误，应用程序开发者和管理员可以采取以下措施：
- 最小化攻击面：应用程序应该最小化攻击面，例如只开放必需的端口、禁用不需要的服务等。
- 加强安全配置：应用程序和组件应该采用最佳安全配置实践，例如使用强密码、启用错误消息的显示、关闭调试模式等。
- 禁用外部实体：应用程序应该禁用XML解析器的外部实体功能，例如在解析XML文档时使用禁用外部实体的选项。这样可以有效防止攻击者利用外部实体攻击。
- 实施白名单：应用程序应该实施白名单措施，例如只信任特定的IP地址、域名等等，以减少攻击者利用XXE漏洞的风险。
- 加强输入验证：应用程序应该加强对用户输入的验证，例如限制XML文档中的实体声明，以防止攻击者利用XXE漏洞发送恶意请求。
- 使用安全XML解析器：应用程序可以使用安全的XML解析器，例如谷歌的安全XML解析器或OWASP的ESAPI库，以减少XXE攻击的风险。
- 及时更新：应用程序和组件应该及时更新，以修复已知的安全漏洞。
- 实施安全审计：应用程序和组件应该定期进行安全审计，以查找潜在的配置错误或漏洞，并及时修复它们。
- 强制访问控制：应用程序和组件应该强制访问控制，只授权给需要的用户和角色。
- 安全监控：应用程序和组件应该实施安全监控，包括日志记录、入侵检测和安全事件响应等，以及时发现和应对安全问题。
A06. 危险和过时的组件 Vulnerable and Outdated Components
危险和过时的组件常是由于使用具有已知安全漏洞的第三方组件或库而导致的，攻击者可以利用这些漏洞来攻击应用程序。
具体来说，危险和过时的组件可能包括以下方面：
- 已知的漏洞：应用程序或其组件可能包含已知的安全漏洞，例如Heartbleed、Shellshock等。2017-A09使用含有已知漏洞的组件
- 过时的组件：应用程序或其组件可能使用已过时的第三方组件或库，这些组件或库可能包含已知的安全漏洞，但由于没有及时更新，导致攻击者可以利用这些漏洞来攻击应用程序。
- 不可信的组件来源：应用程序或其组件可能从不可信的组件来源获取组件或库，这些组件或库可能包含恶意代码，攻击者可以利用这些组件来攻击应用程序。
为了应对危险和过时的组件，应用程序开发者和管理员可以采取以下措施：
- 最小化组件：应用程序应该最小化使用第三方组件或库，并仅使用必需的组件。
- 使用可信的组件来源：应用程序应该从可信的组件来源获取组件或库，并使用数字签名来验证组件的完整性和真实性。
- 及时更新：应用程序和组件应该及时更新，以修复已知的安全漏洞，并使用最新的版本。
- 实施漏洞管理：应用程序和组件应该实施漏洞管理，定期扫描应用程序和组件以查找已知的安全漏洞，并及时修复它们。
- 漏洞披露：应用程序和组件应该参考组件供应商的漏洞披露通知，并及时升级组件或库。
- 安全监控：应用程序和组件应该实施安全监控，包括日志记录、入侵检测和安全事件响应等，以及时发现和应对安全问题。
A07. 身份鉴别和身份认证失效 Identification and Authentication Failures
身份鉴别和身份认证失效通常是由于应用程序在身份验证和鉴别过程中存在漏洞或错误而导致的。
具体来说，身份鉴别和身份认证失效可能包括以下方面：
- 弱密码和口令：应用程序可能允许用户使用弱密码和口令进行身份认证，这使得攻击者更容易猜测或破解密码。2017-A02失效的身份认证
- 缺乏多因素身份认证：应用程序可能只使用单一的身份认证方法，例如用户名和密码，而没有使用其他的多因素身份认证方法，例如令牌、生物识别等，这使得攻击者更容易伪造身份。2017-A02失效的身份认证
- 会话管理漏洞：应用程序可能存在会话管理漏洞，例如会话劫持、会话固定、会话注销等，这使得攻击者能够利用被攻击者的身份进行攻击。
- 拒绝服务攻击：应用程序可能受到拒绝服务攻击，例如暴力破解、暴力撞库、暴力扫描等，这会影响用户的身份验证和鉴别过程。
为了应对身份鉴别和身份认证失效，应用程序开发者和管理员可以采取以下措施：
- 使用强密码和口令：应用程序应该要求用户使用强密码和口令，并使用密码策略来强制要求用户遵守密码规则。
- 实施多因素身份认证：应用程序应该实施多因素身份认证，例如令牌、生物识别等，以增强用户身份认证的安全性。
- 加强会话管理：应用程序应该实施会话管理，例如会话劫持检测、会话固定预防、会话注销等，以减少攻击者利用被攻击者的身份进行攻击的可能性。
- 安全认证协议：应用程序应该使用安全的身份认证协议，例如OAuth、OpenID等，以确保身份认证过程的安全性。
- 拒绝服务防护：应用程序应该实施拒绝服务防护措施，例如限制登录尝试次数、IP地址过滤、验证码等，以减少暴力破解、暴力撞库等拒绝服务攻击的影响。
A08. 软件和数据完整性失效 Software and Data Integrity Failures
软件和数据完整性失效通常是由于应用程序在存储、处理或传输数据时存在漏洞或错误而导致的。攻击者可以利用这些漏洞或错误来篡改应用程序中的数据或代码，从而破坏应用程序及数据的完整性。
具体来说，软件和数据完整性失效可能包括以下方面：
- 数据库注入漏洞：应用程序可能受到数据库注入攻击，攻击者可以利用这些漏洞来篡改应用程序中的数据。
- CSRF攻击：应用程序可能受到CSRF攻击，攻击者可以利用这些漏洞来利用用户的身份执行未经授权的操作，例如更改用户密码。
- 不安全的反序列化：攻击者利用应用程序中的反序列化过程，将恶意数据反序列化为可执行代码，以执行恶意操作的漏洞。在反序列化过程中，应用程序将序列化的数据还原为对象或数据结构。攻击者可以通过修改序列化的数据或提供特制的输入来欺骗应用程序，从而执行恶意代码，例如执行远程命令、访问敏感数据或篡改数据等。2017-A08不安全的反序列化
- 文件上传漏洞：应用程序可能存在文件上传漏洞，攻击者可以利用这些漏洞上传包含恶意代码的文件到服务器上，从而破坏应用程序的完整性。
- 代码注入漏洞：应用程序可能受到代码注入攻击，攻击者可以利用这些漏洞将恶意代码注入应用程序中，从而破坏应用程序的完整性。
为了应对软件和数据完整性失效，应用程序开发者和管理员可以采取以下措施：
- 输入验证和过滤：应用程序应该实施输入验证和过滤来防止数据库注入漏洞和代码注入漏洞。
- CSRF防护：应用程序应该实施CSRF防护措施，例如使用CSRF令牌，以防止CSRF攻击。
- 反序列化防护：序列化和反序列化应该仅限于可信的数据源。应该使用安全的序列化库和算法，例如JSON或Protobuf，而不是不安全的序列化技术，例如Java的ObjectInputStream类。
- 文件上传验证：应用程序应该对上传的文件进行验证和过滤，以防止文件上传漏洞。
- 安全编码实践：应用程序开发者应该使用安全编码实践来避免代码注入漏洞和其他类型的漏洞。
- 加强访问控制：应用程序应该实施访问控制措施，例如身份验证和授权，以防止未经授权的数据或代码修改。
- 加强日志和监控：应用程序应该实施日志和监控措施，例如记录所有用户操作和异常情况，以及及时响应和处理安全事件。
A09. 安全记录及监控失效 Security Logging and Monitoring Failures
安全记录及监控失效通常是由于应用程序未能正确记录、监控和响应安全事件而导致的。这些安全事件可能包括潜在的攻击、异常行为、系统故障等等。
具体来说，安全记录及监控失效可能包括以下方面：
- 缺少安全日志记录：应用程序未能正确记录安全事件，例如登录尝试、身份验证失败、系统错误等等。
- 缺少安全监控：应用程序未能实施安全监控措施，例如检测异常行为、威胁情报、漏洞扫描结果等等。
- 缺少响应计划：应用程序未能实施安全响应计划，例如在安全事件发生时采取适当的行动来遏制威胁、减少损失等等。
为了应对安全记录及监控失效，应用程序开发者和管理员可以采取以下措施：
- 实施安全日志记录：应用程序应该实施安全日志记录措施，例如记录登录尝试、身份验证失败、系统错误等等。
- 实施安全监控措施：应用程序应该实施安全监控措施，例如实时监测异常行为、威胁情报、漏洞扫描结果等等。
- 实施安全响应计划：应用程序应该实施安全响应计划，例如在安全事件发生时采取适当的行动来遏制威胁、减少损失等等。
- 加强访问控制：应用程序应该实施访问控制措施，例如限制用户权限、记录所有用户操作等等，以便快速检测和响应安全事件。
- 加强安全培训和意识：应用程序开发者和管理员应该接受安全培训和意识教育，以了解安全记录及监控的重要性，并学会如何识别和应对安全事件。
A10. 服务器端请求伪造 Server-Side Request Forgery (SSRF)
服务器端请求伪造（Server-Side Request Forgery, SSRF）是指攻击者可以利用应用程序的漏洞，欺骗服务器发起网络请求，从而攻击内部系统或云服务。攻击者可以利用SSRF漏洞访问应用程序未授权的外部系统和资源，例如访问内部网络、获取敏感数据等等。
具体来说，SSRF漏洞通常由以下原因导致：
- 输入验证不充分：应用程序未能正确验证用户提供的输入，例如URL参数、请求体等等。
- 信任不合理：应用程序在发起网络请求时信任了不可信的用户输入。
- 未授权访问：应用程序未能正确限制访问权限，导致攻击者可以访问未授权的资源。
为了应对SSRF漏洞，应用程序开发者和管理员可以采取以下措施：
- 实施输入验证：应用程序应该实施输入验证措施，例如验证URL参数、请求体等等，以防止攻击者利用SSRF漏洞发送恶意请求。
- 实施授权机制：应用程序应该实施授权机制，例如限制网络访问权限、验证用户身份等等，以确保只有授权的用户可以访问内部资源。
- 限制网络访问：应用程序应该限制网络访问范围，例如通过防火墙、安全组等等限制网络访问范围，以减少攻击者利用SSRF漏洞的风险。
- 实施白名单：应用程序应该实施白名单措施，例如限制网络访问范围、只信任特定的IP地址、域名等等，以减少攻击者利用SSRF漏洞的风险。
- 加强安全培训和意识：应用程序开发者和管理员应该接受安全培训和意识教育，以了解SSRF漏洞的风险和应对方法，学会如何识别和防止SSRF攻击。
参考来源