OWASP-TOP10-2021

🌾A01：2021-失效的访问控制 Broken Access Control

风险说明
访问控制强制实施策略，使用户无法在其预期权限之外进行操作。失败的访问控制通常会导致未经授权
的信息泄露、修改或销毁所有数据、或在用户权限之外执行业务功能。常见的访问控制脆弱点包括：

• 违反最小特权原则或默认拒绝原则，即访问权限应该只授予特定能力、角色或用户，但实际上任何人都可
  以访问。
• 通过修改 URL（参数篡改或强制浏览）、内部应用程序状态或 HTML 页面，或使用修改 API 请求的攻击工具来绕过访问控制检查。
• 通过提供唯一标识符（不安全的直接对象引用）允许查看或编辑其他人的帐户
• API没有对POST、PUT 和DELETE强制执行访问控制。
• 特权提升。 在未登录的情况下假扮用户或以用户身份登录时充当管理员。
• 元数据操作，例如通过重放或篡改 JSON Web 令牌 (JWT) 来访问控制令牌，或操纵cookie 或隐藏字段以提升权限，或滥用 JWT 失效。
• CORS 配置错误以致允许未授权或不可信的API访问。
• 以未通过身份验证的用户身份强制浏览的通过身份验证时才能看到的页面或作为标准用户身份访问特权页面

预防措施
访问控制只在受信服务器端代码或无服务器API中有效，这样攻击者才无法修改访问控制检查或元数据。

• 除公有资源外，默认为“拒绝访问”。
• 使用一次性的访问控制机制，并在整个应用程序中不断重用它们，包括最小化跨源资源共享 (CORS) 的使用。
• 建立访问控制模型以强制执行所有权记录，而不是简单接受用户创建、读取、更新或删除的任何记录。
• 特别的业务应用访问限制需求应由领域模型强制执行。
• 禁用Web服务器目录列表，并确保文件元数据（例如： .git）和备份文件不存在于Web的根目录中。
• 在日志中记录失败的访问控制，并在适当时向管理员告警（例如：重复故障）。
• 对API和控制器的访问进行速率限制，以最大限度地降低自动化攻击工具带来的危害。
• 当用户注销后，服务器上的状态会话标识符应失效。无状态的JWT令牌应该是短暂的，以便让攻击者的攻击机会窗口最小化。 对于时间较长的JWT，强烈建议遵循OAuth标准来撤销访问。

攻击范例

范例 #1 应用程序在访问帐户信息的SQL调用中使用了未经验证的数据：
pstmt.setString(1, request.getParameter("acct")); 
ResultSet results = pstmt.executeQuery( );
攻击者只需修改浏览器的“acct”参数即可发送他们
想要的任何帐号。如果没有正确验证，攻击者可以访问任何用户帐户。
https://example.com/app/accountInfo?acct=not myacct

范例 #2 攻击者仅强制浏览目标URL。 访问管理页面一定需要管理员权限。
https://example.com/app/getappInfo
https://example.com/app/admin_getappInfo
如果一个未经身份验证的用户可以访问任何页面，那么这是一个缺陷。
如果一个非管理员权限的用户可以访问管理页面，那么这同样也是一个缺陷。

🍓A02：2021-加密机制失效 Cryptographic Failures

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

• 对应用程序处理、存储或传输的数据分类，并根据隐私法、监管要求或业务需求确定哪些数据是敏感的。
• 对于没有必要存储的敏感数据，应当尽快清除，或者通过PCI DSS标记化或拦截。 未存储的数据不能窃取。
• 确保加密存储的所有敏感数据。
• 确保使用了最新的、强大的标准算法、协议和密钥；并且密钥管理到位。
• 确保加密传输过程中的数据，如使用安全协议（例如具有前向保密 (FS) 密码的 TLS、服务器的密码优先级和安全参数）。确保强制执行数据加密，如使用HTTP 严格安全传输协议 (HSTS) 等指令。
• 禁用缓存对包含敏感数据的响应。
• 根据数据分类应用实施所需的安全控制。
• 不要使用FTP 和SMTP 等传统协议来传输敏感数据。
• 使用具有工作因子（延迟因子）的强自适应和加盐散列函数存储密码，例如 Argon2、scrypt、bcrypt 或PBKDF2。
• 必须选择适合操作模式的初始化向量。对于大多数模式，可以使用CSPRNG（密码安全伪随机数生成器）。
  对于需要随机数的模式，则初始化向量 (IV) 不需要使用CSPRNG。 在所有情况下，对于一个固定密钥，永远不应该使用两次IV。
• 始终使用经过验证的加密，而不仅仅是加密。
• 密钥应以加密方式随机生成并作为字节数组存储在内存中。 如果使用密码，则必须通过适当的密码基密钥派生函数将其转换为密钥。
• 确保在适当的地方使用加密随机性，并且没有以可预测的方式或低熵进行播种。 大多数现代 API 不需要开发人员为 CSPRNG 设置种子以获得安全性。
• 避免使用的已废弃的加密函数和填充方案，例如 MD5、SHA1、PKCS number 1 v1.5。
• 单独验证每个安全配置项的有效性。
  攻击范例

范例 #1
一个应用程序使用自动化的数据加密系统加密存储中数据库中的信用卡号。 
但是，这些数据在检索时会自动解密，这就使得SQL 注入漏洞以明文形式获得信用卡号。

范例 #2
一个网站对所有网页没有使用或对强制使用TLS ，或者使用弱加密。 攻击者经过监测网络流量（例如，在不安全的无线网络中），将网络连接从 HTTPS 降级到 HTTP，就可以拦截请求并窃取用户会话cookie。
 之后，攻击者重放这个cookie 并劫持用户的（经过身份验证的）会话，访问或修改用户的私人数据。 
 除此之外，攻击者还可以更改所有传输过程中的数据，例如，汇款的接收人。

范例 #3
密码数据库使用未加盐或弱哈希算法来存储每个人的密码。一个文件上传漏洞允许攻击者获取密码数据库。 所
有未加盐哈希的密码都可以通过预先计算的哈希值彩虹表破解。 由简单或快速散列函数生成的加盐哈希也可能
通过GPU 破解。

🍉A03：2021-注入Injection

预防措施
防止注入需要将数据与命令和查询分开：

• 推荐的选择是使用安全的API，这样可以避免完全使用解释器、提供参数化接口或迁移到对象关系映射工具（ORM）。注意：即使参数化，如果PL/SQL或T-SQL将查询和数据连接起来，或者使用EXECUTE IMMEDIATE或exec（）执行恶意数据，则存储过程仍然可以引入SQL注入。
• 使用肯定（positive）或“白名单”服务器端输入验证。这并不是一种完美的防御，因为许多应用
  程序需要特殊字符，例如移动应用程序中的文本区域或API。
• 对于任何残余的动态查询，请使用该解释器的特定转义语法转义特殊字符。注意：SQL结构（如表名、列名等）无法转义，因此用户提供的结构名是危险的。这是报表编写软件中的常见问题。
• 在查询中使用LIMIT和其他SQL控件，以防止在SQL注入的情况下大量披露记录。

攻击范例

范例 #1
类似地，应用程序对框架的盲目信任可能会导致易受攻击的查询（例如，Hibernate查询语言（HQL））
Query HQLQuery = session.createQuery("FROM accounts
WHERE custID='" + request.getParameter("id") + "'");
在这两种情况下，攻击者都会修改浏览器中的“id”参数值，
以发送：'或'1'='1。例如：
http://example.com/app/accountView?id=' or '1'='1
这将更改两个查询的含义，以返回accounts表中的所有记录。
更危险的攻击可能会修改或删除数据，甚至调用存储过程。

🍈A04：2021-不安全设计 Insecure Design

预防措施

• 与应用安全专业人员建立并使用安全的开发生命周期，以帮助评估和设计与安全和隐私相关的控制。
• 建立并使用安全设计模式的库，或使用AppSec规划中现有的要素。
• 对关键身份验证、访问控制、业务逻辑和密钥流使用威胁建模。
• 将安全语言和安全控制集成到用户故事中。
• 在应用程序的每一层（从前端到后端）集成合理性检查。
• 编写单元和集成测试，以验证所有关键流是否能够抵抗威胁模型。为应用程序的每一层编译正确用例和误用案例。
• 根据暴露和保护需要，对系统层和网络层进行分层。
• 通过设计在所有层中严格隔离租户。
• 限制用户或服务的资源消耗

攻击范例

范例 #1
一家连锁电影院允许团体预订折扣，支持最多15名观众而不要押金。攻击者可以对这种流量进行威胁建模，
并测试他们是否可以在几个请求中同时预订600个座位和所有电影院，从而造成巨大的收入损失。

🍨 A05：2021-安全配置错误 Security Misconfiguration

预防措施
应实施安全的安装过程，包括：

• 一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。开发、质量保证和生产环境都应该进行相同配置，并且在每个环境中使用不同的密码。这个过程应该是自动化的，以尽量减少安装一个新安全环境的耗费。
• 搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和示例。移除或不安装不适用的功能和框架。
• 检查和修复安全配置项来适应最新的安全说明、更新和补丁，并将其作为更新管理过程的一部分（参见“A6:2021-脆弱和过时的组件”）。在检查过程中，应特别注意云存储权限（如：S3桶权限）。
• 一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构，包括：分段、容器化和云安全组（ACL）。
• 向客户端发送安全指令，例如：安全标头。
• 一个能够验证所有环境中进行了正确的安全配置和设置的自动化过程。

攻击范例

范例 #1
目录列表在服务器端未被禁用。攻击者发现他们很容易就能列出目录列表。攻击者找到并下载所有
已编译的Java类，他们通过反编译来查看代码。然后，攻击者在应用程序中找到一个严重的访问控制漏洞。

🔎A06：2021-自带缺陷和过时的组件 Vulnerable and Outdated Components

预防措施
应制定一个补丁管理流程：

• 移除不使用的依赖、不需要的功能、组件、文件和文档。
• 利用如versions、OWASP Dependency Check、retire.js等工具来持续的记录客户端和服务器端以及它们的依赖库的版本信息。持续监控如CVE和NVD等是否发布已使用组件的漏洞信息，可以使用软件分析工具来自动完成此功能。订阅关于使用组件安全漏洞的警告邮件。
• 仅从官方渠道安全的获取组件，并使用签名机制来降低组件被篡改或加入恶意漏洞的风险 (参见“A08:2021-软件和数据完整性故障”)。
• 监控那些不再维护或者不发布安全补丁的库和组件。如果不能打补丁，可以考虑部署虚拟补丁来监控、检测或保护

范例 #1
通常组件都是以与应用相同的权限运行的，这使得组件里的缺陷可能导致各式各样的问题。这些缺陷可能
是偶然的（如：编码错误），也可能是蓄意的（如：组件里的后门）。下面是一些已被利用的漏洞：
CVE-2017-5638，一个Struts2远程执行漏洞。可在服务端远程执行代码，并已造成巨大的影响。
虽然物联网（IoT）设备一般难以通过打补丁来修复。但对它打补丁非常重要（例如：医疗设
备）。
有些自动化工具能帮助攻击者发现未打补丁的或配置不正确的系统。例如：Shodan IOT搜索引
擎能帮助您发现从2014年4月至今仍存在心脏出血漏洞的设备。

🚩A07：2021-身份识别和身份验证错误 Identification and Authentication Failures

预防措施

• 在可能的情况下，实施多因素认证来防止自动化撞库攻击、暴力破解、以及遭窃认证资讯被重复利用的攻击。
• 不要交付或部署任何预设的认证凭证，特别是管理者。
• 实施弱密码的检查，如测试新设定或变更的密码是否存在于前10000个最差密码清单。
• 将密码长度、复杂度和轮换政策与NIST 800-63b文件“第5.1.1节-被记忆的秘密或其他现代基于
  证据的密码政策”的内容保持一致。
• 对所有结果使用相同的讯息回应，确保注册、认证凭据回复以及API路径能够抵御帐号枚举攻击。
• 限制或增加登入失败尝试的延迟。记录所有失败并于侦测到撞库、暴力破解或其他攻击时发出告警。
• 使用服器端、安全的内建会话管理器，在登入后产生有高熵值的新随机会话ID。会话ID不应出现
  在URL中，必须被安全的储存，并且在登出后、闲置、超时后被注销。

攻击范例

情境#1:
使用已知列表密码的撞库攻击是一种常见的攻击方式，假设应用沒有实施自动化威胁或撞
库攻击的保护，在这种情況下，应用会被利用为密码预报的工具来判断认证凭据是否有效。

情境#2:
应用会话超时设置错误。一个用户使用公用电脑来访问应用时，用户没有选择“登出”而是简单的
关闭浏览器标签页就离开。一小时后，一个攻击者使用同一个浏览器，而那个应用仍处于前面用户
认证通过的状态。

🎈 A08：2021-软件和数据完整性故障 Software and Data Integrity Failures

预防措施

• 使用数字签名或类似机制来验证软件或数据来自预期来源，且未被修改。
• 确保库和依赖项目，如：npm 或 Maven，正在使用受信任的存储库。如果您的风险较高，请考虑托管一个经过审核的、内部已知合格的存储库。
• 确保使用软件供应链安全工具（如：OWASP Dependency Check 或 OWASP CycloneDX）来验证组件不包含已知漏洞。
• 确保对代码和配置更改进行审核，以最大限度地减少恶意代码或配置引入软件管道的可能性。
• 确保您的CI/CD管道具有适当的隔离、配置和访问控制，以确保代码在构建和部署过程中的完整性。
• 确保通过特定形式的完整性检查或数字签名来检测序列化数据是否存在篡改或重播，所有未签名或未加密的序列化数据不会发送到不受信任的客户端。

攻击范例

范例 #1无需签名既可更新
许多家庭路由器、机顶盒、设备固件和其他设备通过没有签名的固件进行更新。未签名固
件是越来越多的攻击者的目标，预计情况只会变得更糟。这是一个主要问题，因为很多时候
除了在未来的版本中修复和等待以前的版本过期之外，没有任何其他补救措施。

🎉A09：2021-安全日志和监控故障 Security Logging and Monitoring Failures

预防措施
开发人员应根据应用的风险，实施以下部分或全部控制：

• 确保所有的登录、访问控制和服务器端输入验证失败都可以被记录在足够的用户上下文中，以识别可疑或恶意的帐户，并保留足够的时间以允许延迟的取证分析。
• 确保日志是日志管理解决方案以方便使用的格式生成的。
• 确保日志数据被正确编码加密，以防止对日志或监控系统的注入或攻击。
• 确保高价值交易有完整性控制的审计跟踪，以防止篡改或删除，例如：只附加数据库表或类似的内容。
• DevSecOps团队应该建立有效的监控和警报，以便发现可疑的活动并迅速做出反应。
• 建立或采用事故应对和恢复计划，例如：美国国家标准技术研究所(NIST)800-61r2或更高版本。
• 有一些商业和开源的应用程序保护框架，如：OWASP ModSecurity核心规则集，以及开源的日志相关软件，如：Elasticsearch、Logstash、Kibana（ELK），具有自定义仪表盘和告警功能。

攻击范例

范例 #1
印度一家大型航空公司发生数据泄露事件，涉及数百万乘客十多年的个人信息，包括护照和信用卡信息。
数据泄露发生在一家第三方云托管服务提供商，该提供商在一段时间后通知了航空公司此次泄露事件。

🔖A10：2021-服务端请求伪造 Server-Side Request Forgery

预防措施
开发者可以通过实现以下部分或全部防御手段，纵深防御来阻止 SSRF:
网络层防御建议：

• 在隔离的网络中设置多个远程资源访问功能的网段，以减少SSRF的影响。
• 执行“默认拒绝”防火墙策略或网络访问控制规则，以阻止除必要的内部网通信外的所有通信。
  提示:
  建立基于应用的防火墙规则的所有权和生命周期。
  在防火墙上记录所有接受和阻止的网络流(参见“A09:2021-安全日志和监控故障”)。

应用层防御建议：

• 检查和验证所有客户端提供的输入数据。
• 使用白名单允许列表允许列表执行URL统一资源标志符、端口和目标。
• 不要给客户端发送原始的回复。
• 禁用 HTTP 重定向。
• 注意URL的一致性，以避免DNS重新绑定和“检查时间，使用时间”(TOCTOU)竞争条件等攻击。
• 不要通过使用黑名单拒绝列表或正则表达式来缓解SSRF。攻击者拥有有效载荷列表、工具和绕过拒绝列表的技能。

需额外考虑的措施:

• 不要在前端系统上部署其他与安全相关的服务（如：OpenID）。控制这些系统上的本地流量（如：localhost）。
• 对于专用和可管理的前端用户，可以在独立系统上使用网络加密（如：vpn）来满足非常高的安全保护需求。

攻击范例

范例 #1内部服务器端口扫描
如果网络架构未进行网络隔离，攻击者可以访问并绘制出内部网络地图，并根据连接结果或
SSRF有效载荷连接的运行时间和拒绝时间判断内部服务器端口是打开还是关闭。

范例 #2敏感数据泄露
攻击者可以访问本地文件或内部服务，以获得敏感信息，例如：
file:///etc/passwd</span>http://localhost:28017/。

范例 #3危害内部服务
攻击者可以滥用内部服务进行进一步的攻击，比如：远程代码执行（RCE）或者拒绝服务攻击（DoS）。