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 攻打。
文章仅供作者学习备忘，如有谬误欢送评论区斧正。
参考起源
https://owasp.org/www-project-top-ten/
https://zhuanlan.zhihu.com/p/453424697