A01:2021 – Broken Access Control
A01：2021 – 访问控制中断
概述
从第五位上升到第五位，94%的应用程序接受了某种形式的中断访问控制的测试，平均发生率为3.81%，并且在贡献的数据集中发生次数最多，超过318k。包括值得注意的常见弱点枚举（CWE-200：敏感信息暴露给未经授权的行为者，CWE-201：通过发送的数据暴露敏感信息， 和CWE-352：跨站点请求伪造。
描述
访问控制强制实施策略，以便用户不能在其预期权限之外执行操作。故障通常会导致未经授权的信息泄露、修改或破坏所有数据，或在用户限制之外执行业务功能。常见的访问控制漏洞包括：
-
默认情况下违反最小特权或拒绝原则，其中应仅向特定功能、角色或用户授予访问权限，但任何人都可以使用。
-
通过修改 URL（参数篡改或强制浏览）、内部应用程序状态或 HTML 页面，或者使用攻击工具修改 API 请求来绕过访问控制检查。
-
通过提供他人的唯一标识符（不安全的直接对象引用）来允许查看或编辑他人的帐户
-
访问缺少 POST、PUT 和 DELETE 访问控制的 API。
-
特权提升。在不登录的情况下充当用户，或在以用户身份登录时充当管理员。
-
元数据操作，例如重播或篡改 JSON Web 令牌 （JWT） 访问控制令牌，或者操纵 Cookie 或隐藏字段以提升权限或滥用 JWT 失效。
-
CORS 配置错误允许从未经授权/不受信任的源进行 API 访问。
-
以未经身份验证的用户身份强制浏览经过身份验证的页面，或以标准用户身份强制浏览特权页面。
如何预防
访问控制仅在受信任的服务器端代码或无服务器 API 中有效，攻击者无法修改访问控制检查或元数据。
-
除公共资源外，默认情况下应拒绝。
-
只需实施一次访问控制机制，即可在整个应用程序中重复使用它们，包括最大限度地减少跨域资源共享 （CORS） 的使用。
-
模型访问控制应强制实施记录所有权，而不是接受用户可以创建、读取、更新或删除任何记录。
-
域模型应强制实施独特的应用程序业务限制要求。
-
禁用 Web 服务器目录列表，并确保文件元数据（例如 .git）和备份文件不存在于 Web 根目录中。
-
记录访问控制失败，在适当时提醒管理员（例如，重复失败）。
-
速率限制 API 和控制器访问，以最大限度地减少自动攻击工具的危害。
-
注销后，有状态会话标识符应在服务器上失效。无状态 JWT 令牌应该是短暂的，以便将攻击者的机会之窗降至最低。对于寿命较长的 JWT，强烈建议遵循 OAuth 标准来撤销访问权限。
开发人员和 QA 人员应包括功能访问控制单元和集成测试。
攻击场景示例
场景 #1：应用程序在访问帐户信息的 SQL 调用中使用未经验证的数据：
pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
攻击者只需修改浏览器的"acct"参数即可发送他们想要的任何帐号。如果未正确验证，攻击者可以访问任何用户的帐户。
https://example.com/app/accountInfo?acct=notmyacct
场景 #2：攻击者只是强制浏览以 URL 为目标。访问管理页面需要管理员权限。
https://example.com/app/getappInfo
https://example.com/app/admin_getappInfo
如果未经身份验证的用户可以访问任一页面，则这是一个缺陷。如果非管理员可以访问管理页面，则这是一个缺陷。
引用
映射的 CWE 列表
CWE-59 在文件访问之前不正确的链接解析（"链接跟踪"）
CWE-601 URL 重定向到不受信任的站点（"打开重定向"）
CWE-1275 具有不正确的同一站点属性的敏感 Cookie
A02：2021 – 加密失败
概述
将一个位置移动到#2，以前称为敏感数据暴露，这更像是一个广泛的症状，而不是根本原因，重点是与加密相关的故障（或缺乏密码学）。这通常会导致敏感数据的泄露。值得注意的常见弱点枚举（CWE）包括CWE-259：使用硬编码密码，CWE-327：破碎或有风险的加密算法和CWE-331熵不足。
描述
第一件事是确定传输中和静态数据的保护需求。例如，密码、信用卡号、健康记录、个人信息和商业秘密需要额外的保护，前提是这些数据属于隐私法（如欧盟的《通用数据保护条例》（GDPR））或法规（如PCI数据安全标准（PCI DSS））的监管范围。对于所有此类数据：
-
是否有任何数据以明文形式传输？这涉及HTTP，SMTP，FTP等协议也使用TLS升级，如STARTTLS。外部互联网流量是危险的。验证所有内部流量，例如，负载均衡器、Web 服务器或后端系统之间的流量。
-
是否有任何旧的或弱的加密算法或协议在默认情况下使用或在较旧的代码中使用？
-
是否正在使用默认加密密钥、生成或重用的弱加密密钥，或者是否缺少正确的密钥管理或轮换？加密密钥是否签入源代码存储库？
-
是否未强制执行加密，例如，是否缺少任何 HTTP 标头（浏览器）安全指令或标头？
-
收到的服务器证书和信任链是否经过正确验证？
-
初始化向量是否被忽略、重用或生成对于加密操作模式不够安全？是否正在使用欧洲央行等不安全的操作模式？当经过身份验证的加密更合适时，是否使用加密？
-
在没有密码基本密钥派生功能的情况下，密码是否被用作加密密钥？
-
随机性是否用于不满足加密要求的加密目的？即使选择了正确的函数，它是否需要由开发人员进行种子设定，如果没有，开发人员是否用缺乏足够熵/不可预测性的种子覆盖了内置的强大种子设定功能？
-
是否正在使用已弃用的哈希函数（如 MD5 或 SHA1），还是在需要加密哈希函数时使用非加密哈希函数？
-
是否正在使用已弃用的加密填充方法（如 PKCS 编号 1 v1.5）？
-
加密错误消息或侧信道信息是否可被利用，例如以填充预言机攻击的形式？
请参阅 ASVS 加密 （V7）、数据保护 （V9） 和 SSL/TLS （V10）
如何预防
至少执行以下操作，并查阅参考资料：
-
对应用程序处理、存储或传输的数据进行分类。根据隐私法律、法规要求或业务需求确定哪些数据是敏感的。
-
不要不必要地存储敏感数据。尽快丢弃它或使用符合PCI DSS标准的标记化甚至截断。未保留的数据不会被盗。
-
确保加密静态所有敏感数据。
-
确保最新且强大的标准算法、协议和密钥到位;使用适当的密钥管理。
-
使用安全协议（如具有前向保密 （FS） 密码的 TLS）、服务器的密码优先级和安全参数，对传输中的所有数据进行加密。使用 HTTP 严格传输安全 （HSTS） 等指令强制实施加密。
-
禁用包含敏感数据的响应的缓存。
-
根据数据分类应用所需的安全控制。
-
不要使用 FTP 和 SMTP 等旧协议来传输敏感数据。
-
使用具有工作因子（延迟因子）的强自适应和盐渍散列函数（例如Argon2，scrypt，bcrypt或PBKDF2）存储密码。
-
必须选择适合操作模式的初始化向量。对于许多模式，这意味着使用CSPRNG（加密安全的伪随机数生成器）。对于需要随机数的模式，则初始化向量 （IV） 不需要 CSPRNG。在所有情况下，对于固定密钥，IV 绝不应使用两次。
-
始终使用经过身份验证的加密，而不仅仅是加密。
-
密钥应以加密方式随机生成，并作为字节数组存储在内存中。如果使用密码，则必须通过适当的密码基本密钥派生函数将其转换为密钥。
-
确保在适当的情况下使用加密随机性，并且未以可预测的方式或低熵进行种子设定。大多数现代 API 不需要开发人员为 CSPRNG 设定种子即可获得安全性。
-
避免使用已弃用的加密函数和填充方案，例如 MD5、SHA1、PKCS 编号 1 v1.5。
-
独立验证配置和设置的有效性。
攻击场景示例
方案 #1：应用程序使用自动数据库加密对数据库中的信用卡号进行加密。但是，此数据在检索时会自动解密，从而允许 SQL 注入缺陷以明文形式检索信用卡号。
场景#2：网站不对所有页面使用或强制实施TLS或支持弱加密。攻击者监视网络流量（例如，在不安全的无线网络上），将连接从 HTTPS 降级为 HTTP，拦截请求并窃取用户的会话 Cookie。然后，攻击者重放此 Cookie 并劫持用户的（经过身份验证的）会话，访问或修改用户的私人数据。相反，他们可以改变所有传输的数据，例如，汇款的接收者。
方案#3：密码数据库使用无盐或简单哈希来存储每个人的密码。文件上传缺陷允许攻击者检索密码数据库。所有无盐哈希都可以使用预先计算的哈希的彩虹表公开。由简单或快速哈希函数生成的哈希值可能会被 GPU 破解，即使它们经过盐渍处理。
引用
映射的 CWE 列表
CWE-335 种子在伪随机数生成器 （PRNG） 中的错误用法
CWE-337 伪随机数生成器 （PRNG） 中的可预测种子
CWE-720 OWASP 2007年十大类别A9 - 不安全的通信
CWE-757 协商过程中安全性较低的算法选择（"算法降级"）
CWE-780 在没有 OAEP 的情况下使用 RSA 算法
以上翻译仅提供参考，如有更好的翻译欢迎指正
http://owasp.org/www-project-top-ten/
扫一扫
799
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
