描述
产品执行授权检查当演员试图访问资源或执行一个动作,但它不正确执行检查。这允许攻击者绕过访问限制。
扩展描述
假设一个用户与给定的身份,授权是一个过程,确定该用户是否可以访问给定的资源,基于用户的特权和权限或其他访问控制规范,适用于资源。
访问控制检查错误地应用时,用户可以访问数据或执行行动,他们不应该被允许执行。这可能导致各种各样的问题,包括信息曝光、拒绝服务和执行任意代码。
替代条款
AuthZ:
“AuthZ”通常是用作缩写web应用程序安全社区内的“授权”。它是不同于“AuthN”(或者,有时候,“AuthC”)这是一个缩写的“认证”。The use of "Auth" as an abbreviation is discouraged, since it could be used for either authentication or authorization.
的关系
此表显示了弱点和高水平类别相关的这一弱点。这些关系被定义为ChildOf、ParentOf MemberOf,并洞察类似项目可能存在的在较高和较低的抽象级别。此外,关系如PeerOf和CanAlsoBe定义显示类似的弱点,用户可能想要探索。
相关的视图”研究概念”(cwe - 1000)
自然
类型
ID
的名字
ChildOf
类——一个弱点,描述的是一个非常抽象的时尚,通常独立于任何特定的语言或技术。更具体的比一个支柱的弱点,但更普遍的基本的弱点。类级别的弱点通常描述问题的1或2以下维度:行为、财产和资源。
285年
不适当的授权
ParentOf
Base -一个弱点,仍主要是独立的资源或技术,但有足够的细节来提供特定的检测和预防方法。基础水平的弱点通常描述问题的2或3以下维度:行为、财产、技术、语言,和资源。
551年
不正确的行为秩序:授权之前解析和规范化
ParentOf
Base -一个弱点,仍主要是独立的资源或技术,但有足够的细节来提供特定的检测和预防方法。基础水平的弱点通常描述问题的2或3以下维度:行为、财产、技术、语言,和资源。
639年
授权旁路通过用户控制的关键
ParentOf
变体——一个弱点与某种类型的产品,通常涉及到一个特定的语言或技术。更具体的比基本的弱点。变异水平弱点通常描述问题的3到5以下维度:行为、财产、技术、语言,和资源。
647年
使用非规范的URL路径进行授权决策
ParentOf
Base -一个弱点,仍主要是独立的资源或技术,但有足够的细节来提供特定的检测和预防方法。基础水平的弱点通常描述问题的2或3以下维度:行为、财产、技术、语言,和资源。
804年
可推测的验证码
ParentOf
Base -一个弱点,仍主要是独立的资源或技术,但有足够的细节来提供特定的检测和预防方法。基础水平的弱点通常描述问题的2或3以下维度:行为、财产、技术、语言,和资源。
1244年
内部资产暴露于不安全的访问级别调试或状态
此表显示了弱点和高水平类别相关的这一弱点。这些关系被定义为ChildOf、ParentOf MemberOf,并洞察类似项目可能存在的在较高和较低的抽象级别。此外,关系如PeerOf和CanAlsoBe定义显示类似的弱点,用户可能想要探索。
简化映射的相关视图”缺点漏洞发布”(cwe - 1003)
自然
类型
ID
的名字
ParentOf
Base -一个弱点,仍主要是独立的资源或技术,但有足够的细节来提供特定的检测和预防方法。基础水平的弱点通常描述问题的2或3以下维度:行为、财产、技术、语言,和资源。
639年
授权旁路通过用户控制的关键
此表显示了弱点和高水平类别相关的这一弱点。这些关系被定义为ChildOf、ParentOf MemberOf,并洞察类似项目可能存在的在较高和较低的抽象级别。此外,关系如PeerOf和CanAlsoBe定义显示类似的弱点,用户可能想要探索。
相关视图”架构概念”(cwe - 1008)
自然
类型
ID
的名字
MemberOf
类别——CWE条目包含一组其他条目,共享一个共同的特点。
1011年
授权的演员
此表显示了弱点和高水平类别相关的这一弱点。这些关系被定义为ChildOf、ParentOf MemberOf,并洞察类似项目可能存在的在较高和较低的抽象级别。此外,关系如PeerOf和CanAlsoBe定义显示类似的弱点,用户可能想要探索。
相关的视图”方案及数据保护措施”(cwe - 1340)
自然
类型
ID
的名字
ChildOf
支柱——一个弱点是最抽象类型的弱点和代表一个主题类/基地/变体相关弱点。支柱是不同于一个类别作为支柱技术上仍然是一种弱点,描述了一个错误,而一个类别代表一个共同特征用于组相关的东西。
284年
访问控制不当
背景细节
一个访问控制列表(ACL)代表世卫组织/给定对象的权限。不同的操作系统以不同的方式实现(acl)。在UNIX中,有三种类型的权限:读、写和执行。文件访问用户分为三类:所有者、群组的所有者,和所有其他用户,每个类都有一个独立的权利。在Windows NT,有四种基本类型的权限文件:“不能”,“读访问权”,“改变访问”和“完全控制”。Windows NT延伸的概念在UNIX中三种类型的用户,包括用户和组列表及其相关的权限。用户可以创建一个对象(文件),并将指定的权限分配给该对象。
模式的介绍
不同模式的引入提供了信息如何以及何时可以纳入这一弱点。生命周期的阶段识别点的介绍可能发生,而相关的报告提供了一个典型的场景介绍在给定的阶段。
阶段
请注意
架构和设计
授权的弱点可能出现当一个单用户应用程序移植到一个多用户环境。
实现
实现:造成这一弱点在建筑安全策略的实施。
开发人员可能会引入授权弱点由于缺乏了解底层技术。例如,开发人员可能假设攻击者不能修改某些输入标题或饼干等。
操作
常见的后果
这个表指定不同的个人相关后果的弱点。标识应用程序范围的安全领域侵犯,而影响了负面的技术影响,如果敌人成功利用这个弱点。可能提供的信息如何可能的具体结果预计将看到列表中相对于其它后果。例如,可能会有高可能性,缺点将被利用来实现一定的影响,但较低的可能性,它将被利用来实现不同的影响。
范围
影响
可能性
保密
攻击者可以读取敏感数据,通过阅读直接从数据存储的数据不正确的限制,或通过访问保护不足,特权功能读取数据。
完整性
攻击者可以修改敏感数据,通过将数据直接写入一个数据存储这不是正确的限制,或通过访问保护不足,特权功能写数据。
访问控制
攻击者可以获得特权直接通过修改或阅读关键数据,或通过访问特权功能。
利用的可能性
示范例子
示例1
下面的代码可以为医疗记录应用程序。它显示一个记录已经过身份验证的用户,确认用户的授权使用一个值存储在一个cookie。
角色= _COOKIES美元(的作用);
如果(! $角色){
美元的作用= getRole(“用户”);
如果美元(角色){
/ /保存cookie将来发送响应 setcookie(“角色”,美元的角色,时间()+ 60 * 60 * 2);
}
其他{
ShowLoginScreen (); 死亡(“\ n”);
}
}
如果($角色= =“读者”){
DisplayMedicalHistory ($ _POST [' patient_ID ']);
}
其他{
死亡(“你未被授权查看这些记录\ n”);
}
程序员希望饼干只能设置当getRole()成功。程序员甚至努力指定两个小时过期的饼干。然而,攻击者可以很容易地设置“角色”饼干“读者”的价值。因此,$角色变量是“读者”,getRole()调用。攻击者绕过授权系统。
观察到的例子
参考
描述
网关使用默认为其授权设置“允许”配置。
链:产品不正确解释系统组的配置选项,允许用户获得特权。
链:SNMP产品不正确解析配置选项允许哪些主机连接,允许未经授权的IP地址连接。
链:产品不妥善处理通配符的授权策略列表,允许意外访问。
ACL-based保护机制对待消极的访问权限,好像他们是积极的,允许绕过限制。
产品依赖于HTTP报头X-Forwarded-For授权,允许意外访问通过欺骗的头。
链:产品不正确检查反向DNS查询的结果,因为操作符优先级(
cwe - 783 ),允许绕过以域名系统的访问限制。
潜在的缓解措施
阶段:体系结构和设计
将产品划分为匿名的,正常的,特权和行政区域。减少攻击表面通过仔细映射角色的数据和功能。使用基于角色的访问控制(RBAC) (
ref - 229 )执行的角色在适当的界限。
注意,这个方法可能不是防止水平授权,即。,它不会保护用户免受攻击别人用同样的角色。
阶段:体系结构和设计
确保访问控制检查执行相关的业务逻辑。这些检查可能是不同的访问控制检查应用于更通用的资源,比如文件、连接、进程、内存和数据库记录。例如,一个数据库可能限制医疗记录到一个特定的数据库的访问用户,但每个记录可能只是为了访问病人和病人的医生
REF-7 ]。
阶段:体系结构和设计
使用审查库或框架不允许这个弱点发生或提供了结构,使这个弱点更容易避免的。
阶段:体系结构和设计
对于web应用程序,确保访问控制机制是正确的每一页都在服务器端执行。用户不能访问任何未经授权的功能或信息,只需请求直接访问该页面。
要做到这一点的方法之一是确保包含敏感信息的所有页面不缓存,,所有此类页面限制访问请求都伴随着一个活跃的和经过身份验证的会话令牌关联到一个用户所需的权限访问该页面。
阶段:系统配置;安装
使用您的操作系统的访问控制功能和服务器环境,并相应地定义访问控制列表。使用“默认否认”政策在定义这些acl。
检测方法
自动静态分析
自动静态分析是有用的检测常用的习语进行授权。一个工具可以分析相关的配置文件,比如. htaccess在Apache web服务器中,或检测常用的使用授权库。
一般来说,自动静态分析工具有困难检测自定义授权模式。即使他们可以定制识别这些计划,他们可能无法正确判断该计划执行授权的方式无法绕过或攻击者破坏了。
自动动态分析
自动动态分析可能无法找到保护授权检查的接口,即使这些检查包含的弱点。
手动分析
这个弱点可以检测使用的工具和技术,需要手动(人类)的分析,如渗透测试、威胁建模和交互工具,允许测试人员记录和修改一个活跃的会话。
具体来说,手工静态分析有助于评估自定义授权机制的正确性。
注意: 这些可能是更有效的比严格的自动化技术。尤其如此弱点设计和相关的业务规则。然而,手动努力可能不会在有限时间内达到所需的代码覆盖约束。
人工静态分析——二进制或字节码
根据飙升,以下检测技术可能是有用的:
动态分析与自动化的结果解释
根据飙升,以下检测技术可能是有用的:
Web应用程序扫描
Web服务的扫描仪
数据库扫描仪
动态分析与人工解释结果
根据飙升,以下检测技术可能是有用的:
人工静态分析源代码
根据飙升,以下检测技术可能是有用的:
关注人工抽查,手动分析来源
手工源代码审查(不检查)
自动静态分析源代码
根据飙升,以下检测技术可能是有用的:
体系结构或设计审查
根据飙升,以下检测技术可能是有用的:
会员资格
这MemberOf关系表显示额外CWE类别和视图引用这个弱点作为成员。这些信息通常是有用的在理解一个弱点符合外部信息源的上下文中。
引用
(ref - 62)马克·多德约翰麦克唐纳和贾斯汀Schuh。“软件安全评估的艺术”。第二章,“常见的漏洞授权”,39页。1版。艾迪生卫斯理》2006。