[系统运维]OWASP 转载

A01：2021-访问控制中断icon
因素
CWES映射 最大发病率 AVG发病率 AVG加权开发 AVG加权冲击 最大覆盖率 AVG覆盖 总发生次数 共计
34 55.97% 3.81% 6.92 5.93 94.55% 47.72% 318,487 19,013
概述
从第五位开始，94%的应用程序接受了某种类型的访问控制的测试，平均发生率为3.81%，并且在超过318 k的贡献数据集中出现最多。值得注意的常见弱点数字(CWES)包括CWE-200：敏感信息暴露给未经授权的行为者, CWE-201：通过发送的数据曝光敏感信息，和CWE-352：跨站点请求伪造.

描述
访问控制强制执行策略，使用户不能在其预期权限之外执行操作。故障通常会导致未经授权的信息泄露、修改或销毁所有数据，或者在用户权限之外执行业务功能。常见的访问控制漏洞包括：

默认情况下，这违反了最小特权或拒绝的原则，在这种情况下，只能为特定的功能、角色或用户授予访问权限，但任何人都可以访问。

通过修改URL(参数篡改或强制浏览)、内部应用程序状态或HTML页面，或者使用修改API请求的攻击工具，绕过访问控制检查。

允许查看或编辑他人的帐户，提供其唯一标识符(不安全的直接对象引用)

访问API，缺少对POST、PUT和DELETE的访问控制。

特权的提升。以用户身份行事，而不作为用户登录，或在以用户身份登录时充当管理员。

元数据操作，例如重放或篡改JSONWeb令牌(JWT)访问控制令牌，或操纵用于提升权限或滥用JWT无效化的cookie或隐藏字段。

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
如果未经身份验证的用户可以访问任何一个页面，则这是一个缺陷。如果一个非管理员可以访问管理页面，这是一个缺陷。
A02：2021-密码故障icon
因素
CWES映射 最大发病率 AVG发病率 AVG加权开发 AVG加权冲击 最大覆盖率 AVG覆盖 总发生次数 共计
29 46.44% 4.49% 7.29 6.81 79.33% 34.85% 233,788 3,075
概述
将一个位置移到#2，以前称为敏感数据曝光这是一个更广泛的症状，而不是一个根本原因，重点是与密码(或缺乏密码)相关的失败。这往往导致敏感数据的暴露。值得注意的常见弱点数字(CWES)包括CWE-259：使用硬编码密码, CWE-327：破坏或危险的密码算法，和CWE-331熵不足 .

描述
第一件事是确定数据在传输和休息时的保护需求。例如，密码、信用卡号码、健康记录、个人信息和商业秘密需要额外的保护，主要是如果这些数据属于隐私法，例如欧盟的一般数据保护条例(GDPR)或条例，例如金融数据保护，如PCI数据安全标准(PCI DSS)。关于所有这些数据：

是否有任何数据以明文传送？这涉及HTTP、SMTP、FTP等协议，还使用STARTTLS等TLS升级。外部互联网流量是危险的。验证所有内部通信量，例如负载平衡器、Web服务器或后端系统之间的流量.

在默认情况下或在旧代码中是否使用任何旧的或弱的密码算法或协议？

是使用默认密钥，生成或重用弱密钥，还是缺少正确的密钥管理或旋转？密码密钥是否被签入源代码存储库？

是否没有强制加密，例如，是否缺少HTTP报头(浏览器)安全指令或标头？

接收到的服务器证书和信任链是否正确验证？

初始化向量是否被忽略、重用，或者对加密操作模式没有足够的安全性？欧洲央行等不安全的操作模式是否在使用？认证加密时是否使用加密更合适？

在没有密码基密钥派生功能的情况下，密码是否用作加密密钥？

随机性是否用于不满足密码要求的密码目的？即使选择了正确的函数，它是否需要由开发人员播种，如果没有，开发人员是否用缺乏足够的熵/不可预测性的种子改写了内置的强大种子功能？

不建议使用的哈希函数(如MD5或SHA 1)，还是需要加密哈希函数时使用的非加密散列函数？

不推荐的加密填充方法(如PKCS编号1 v1.5)是否正在使用？

密码错误消息或侧通道信息是否可被利用，例如以填充Oracle攻击的形式？

见ASVS Crypto(V7)、数据保护(V9)和SSL/TLS(V10)

如何预防
至少执行以下操作，并查阅参考资料：

对应用程序处理、存储或传输的数据进行分类。根据隐私法、法规要求或业务需求，确定哪些数据是敏感的。

不要不必要地存储敏感数据。尽快抛弃它，或者使用符合PCIDSS的令牌化甚至截断。未保留的数据不能被盗。

确保在休息时加密所有敏感数据。

确保最新和强有力的标准算法、协议和密钥到位；使用适当的密钥管理.

使用安全协议加密传输中的所有数据，例如具有前向保密(FS)密码的TLS、服务器的密码优先级和安全参数。使用HTTP严格传输安全性(HSTS)之类的指令强制加密。

禁用包含敏感数据的响应的缓存。

根据数据分类应用所需的安全控制。

不要使用传统协议(如FTP和SMTP)传输敏感数据。

使用具有工作因子(延迟因子)的强自适应和咸散函数来存储密码，例如Argon2、scrapt、bcrypt或PBKDF 2。

必须选择适合于操作模式的初始化向量。对于许多模式，这意味着使用CSPRNG(加密安全伪随机数生成器)。对于需要nonce的模式，初始化向量(IV)不需要CSPRNG。在任何情况下，IV都不应用于固定的密钥两次。

始终使用经过身份验证的加密，而不是仅仅使用加密。

密钥应该以密码方式随机生成，并作为字节数组存储在内存中。如果使用密码，则必须通过适当的密码基密钥派生函数将其转换为密钥。

确保在适当的情况下使用密码随机性，并确保它没有以可预测的方式或以低熵的方式播种。大多数现代API不要求开发人员为CSPRNG添加种子才能获得安全性。

避免不推荐的加密函数和填充方案，如MD5、SHA 1、PKCS编号1 v1.5。

独立验证配置和设置的有效性。

示例攻击场景
设想方案1应用程序使用自动数据库加密技术对数据库中的信用卡号进行加密。但是，该数据在检索时会自动解密，从而允许SQL注入漏洞检索明文信用卡号码。

情景2：：站点不对所有页面使用或强制使用TLS，也不支持弱加密。攻击者监视网络流量(例如，在不安全的无线网络上)，将连接从HTTPS降为HTTP，拦截请求，并窃取用户的会话cookie。然后攻击者重放此cookie并劫持用户的(经过身份验证的)会话，访问或修改用户的私有数据。它们可以改变所有传输的数据，例如汇款的接受者，而不是上述。

设想方案3密码数据库使用未加盐或简单的散列来存储每个人的密码。文件上载漏洞允许攻击者检索密码数据库。所有未加盐的散列都可以用预先计算过的散列的彩虹表公开。由简单或快速的哈希函数生成的散列可能会被GPU破解，即使它们是加密的。