owasp十大漏洞简单了解

1.

A01：2021 – 访问控制中断

因素

已映射的 CWE	最大发病率	平均发病率	平均加权漏洞	平均加权影响	最大覆盖范围	平均覆盖范围	总发生次数	平均节能总额
34	55.97%	3.81%	6.92	5.93	94.55%	47.72%	318,487	19,013

概述

从第五位上升到第五位，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

如果未经身份验证的用户可以访问任一页面，则这是一个缺陷。如果非管理员可以访问管理页面，则这是一个缺陷。

 

A01：2021 – 访问控制中断

因素

已映射的 CWE	最大发病率	平均发病率	平均加权漏洞	平均加权影响	最大覆盖范围	平均覆盖范围	总发生次数	平均节能总额
34	55.97%	3.81%	6.92	5.93	94.55%	47.72%	318,487	19,013

概述

从第五位上升到第五位，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

如果未经身份验证的用户可以访问任一页面，则这是一个缺陷。如果非管理员可以访问管理页面，则这是一个缺陷。