OWASP A1 Broken Access Control (失效的访问控制)

TOP1 Broken Access Control (失效的访问控制)

替代了17版本的 TOP1 注入

主要包括以下几点

1. 文件包含/目录遍例
2. 权限绕过(水平越权)
3. 权限提升(垂直越权)
4. 不安全直接对象的引用

文件包含/目录遍例

文件包含是如何理解呢?

如果说一个 PHP 开发者希望代码更灵活,避免代码重复,可能就会引入 include 或 require 函数来引入代码,同时指定参数来调用要包含的函数或者函数

当然也可能是别的情况

如果说支持外部网站的文件

?file=http://www.test.com/test.txt

再如果说,支持其他的协议

?file=file:///etc/passwd

或者是探测本地其他服务

?file=http://localhost:8080

那么目录遍例又是如何理解的呢?

大家都知道 …/ 在 Windows 或者 Linux 里面是返回上一个文件夹

但是如果说开发者偷懒,只是写了个文件名字作为参数,比方说
?file=file.php

就可以理解为开发者已经写好了路径 , 比方说/etc/www/cms/,后面再加上 file 传过来的参数合成一块,再去读取那个文件.

也就是说我要的文件路径是

/etc/www/cms/file.php (这里用的绝对路径)

但是我偷偷改了这个参数

改成了 ?file=…/…/…/…/…/etc/passwd

这个时候要查的文件路径为

/etc/www/cms/…/…/…/…/…/etc/passwd

意思变的有意思起来了

经过几次…/

返回到了 / 根目录

此时去到了/etc/passwd

如果你给了足够的权限

那么是会读取到 passwd 文件的内容

Unicode/UTF-8 编码绕过

..％c0％af 表示 ../ 
..％c1％9c 代表 .. \

常见敏感信息路径

Windows

c:\boot.ini // 查看系统版本

c:\windows\system32\inetsrv\MetaBase.xml // IIS配置文件

c:\windows\repair\sam // 存储Windows系统初次安装的密码

c:\ProgramFiles\mysql\my.ini // MySQL配置

c:\ProgramFiles\mysql\data\mysql\user.MYD // MySQL root密码

c:\windows\php.ini // php 配置信息

Linux

/etc/passwd // 账户信息

/etc/shadow // 账户密码文件

/usr/local/app/apache2/conf/httpd.conf // Apache2默认配置文件

/usr/local/app/apache2/conf/extra/httpd-vhost.conf // 虚拟网站配置

/usr/local/app/php5/lib/php.ini // PHP相关配置

/etc/httpd/conf/httpd.conf // Apache配置文件

/etc/my.conf // mysql 配置文件

权限绕过(水平越权)

这个就很好理解了

通过某种手段去访问相同权限,不同用户资源的操作,称之为水平越权

比方说我想看我本人的账户,向服务器发送一个查看我本人信息的请求,但是我在向服务器发送前,利用 BS 截获了

其中内容如下,是要查 test1 的信息

POST /admin/findUser.jsp HTTP/1.1
Host: 127.0.0.1
...
....

userID=test1

我在这里改了一下,变成了要查 test2 的信息

POST /admin/findUser.jsp HTTP/1.1
Host: 127.0.0.1
...
....

userID=test2

如果服务器没有进行验证的话,将会返回的是 test2 的信息

同样道理,你也可以偷偷把号给删了(利用注销机制)

权限提升(垂直越权)

用普通的用户权限,利用一些小操作,获取到更高一级的操作,可以称之为垂直越权

举一个简单的例子

有一个 cms 用 cookie 来辨别是普通用户或者是管理员用户,同时管理员的增删用户界面没有设置访问限制

我是个攻击者,用了个小手段(比方说XSS),获取到了这个管理员的 Cookie ,这个管理员也没有退出管理界面

这个时候

我进入了增加用户的界面,增加用户,不做任何修改

此时发送的包为

POST /admin/addUser.jsp HTTP/1.1
Host: 127.0.0.1
...
....

Cookie: ID=fia4o62d7j

userID=test1

如果我们不做任何修改

肯定会回报权限不足类似的错误

所以我们要把 ID 改为管理员的

POST /admin/addUser.jsp HTTP/1.1
Host: 127.0.0.1
...
....

Cookie: ID=c7imkdlsrv

userID=test1

这时候就会返回正常增加用户的结果

为啥不对用户进行验证?

我在上面说了,通过 cookie 辨别用户权限

这只是个简单的小例子,实际情况可能复杂的多

不安全直接对象的引用

指一个已经授权的用户，通过更改访问时的一个参数，从而访问到了原本其并没有得到授权的对象。

Web应用往往在生成Web页面时会用它的真实名字，且并不会对所有的目标对象访问时来检查用户权限，所以这就造成了不安全的对象直接引用的漏洞。

在这时绕过授权并访问系统中的资源,比方说数据库或者文件

比方说直接进行数据库检索

http://www.test.com/somepage?invoice=12345

如果没有可以通过遍例获取数据

再比方说,功能操作

http://www.test.com/changepassword?user=someuser

其中 user 是告诉程序访问哪些功能,如果没有对功能做限制,那么就很容易造成越权访问,上面的垂直访问就是这样

防御思路

授权是应该授予或拒绝访问特定资源的请求的过程。Web应用程序需要访问控制以允许用户（具有不同的权限）使用该应用程序。他们还需要管理员来管理应用程序访问控制规则以及向用户和其他实体授予权限或权利。提供各种访问控制设计方法。要选择最合适的风险评估，需要执行风险评估以识别特定于您的应用程序的威胁和漏洞，以便适当的访问控制方法适合您的应用程序。

基于角色的访问控制（RBAC）

在基于角色的访问控制（RBAC）中，访问决策基于个人在组织或用户群中的角色和职责。

定义角色的过程通常基于分析组织的基本目标和结构，并且通常与安全策略相关联。例如，在医疗机构中，用户的不同角色可能包括医生，护士，服务员，护士，患者等等。显然，这些成员需要不同级别的访问才能执行其功能，但也需要根据安全政策和任何相关法规（HIPAA，Gramm-Leach-Bliley等）。

RBAC访问控制框架应该为Web应用程序安全管理员提供确定的“谁可以执行哪些操作，何时，从何处，以何种顺序以及在某些情况下在什么关系环境下“执行操作的能力。

使用此方法的优点是：

• 角色是根据组织结构分配的，重点是组织安全策略
• 使用方便
• 易于管理
• 内置于大多数框架中
• 符合职责分离和最低特权等安全原则

使用此方法时可能遇到的问题：

• 必须严格保持角色和访问的文档。
• 除非有办法将角色与多租户功能要求相关联，例如Active Directory中的OU，否则无法有效实施多租户
• 存在范围蔓延的趋势，例如可以给出比预期更多的访问和特权。或者，如果未执行适当的访问查看和后续撤销，则用户可能包含在两个角色中。
• 不支持基于数据的访问控制

使用RBAC时的注意事项是：

• 必须使用严格的签名和流程来转让或委派角色。
• 当用户将其角色更改为另一个角色时，管理员必须确保撤消先前的访问权限，以便在任何给定的时间点，仅在需要知道的基础上将用户分配给那些角色。
• 必须使用严格的访问控制审查来执行RBAC保证。

自由访问控制（DAC）

自由访问控制（DAC）是一种基于用户身份和某些组成员身份限制对信息的访问的方法。访问决策通常基于授权给用户的授权，该授权基于他在认证时呈现的凭证（用户名，密码，硬件/软件令牌等）。在大多数典型的DAC模型中，信息所有者或任何资源都可以自行决定更改其权限 。

DAC框架可以为Web应用程序安全管理员提供实现细粒度访问控制的能力。该模型可以作为基于数据的访问控制的实现的基础 。

使用此模型的优点是：

• 使用方便
• 易于管理
• 符合最小特权原则。
• 对象所有者完全控制授予的访问权限

使用此方法时可能遇到的问题：

• 必须严格保持角色和访问的文档。
• 除非有办法将角色与多租户功能要求相关联，例如Active Directory中的OU，否则无法有效实施多租户
• 存在范围蔓延的趋势，例如可以给出比预期更多的访问和特权。

使用DAC时的注意事项是：

• 在给予信任的同时DAC保证必须使用严格的访问控制审查。

强访问控制（MAC）

强制访问控制（MAC）确保组织安全策略的实施不依赖于Web应用程序用户的合规性。MAC通过在信息上分配敏感标签并将其与用户操作的灵敏度级别进行比较来保护信息。MAC通常适用于极其安全的系统，包括多级安全军事应用或关键任务数据应用。

使用此方法的优点是：

• 对对象的访问权限取决于对象的敏感性
• 严格遵守基于需要知识的访问，并且范围蠕变具有最小可能性
• 只有管理员才能授予访问权限

使用此方法时可能遇到的问题：

• 实施起来困难且昂贵
• 不灵活

使用MAC时的注意事项是：

• 在适当和务实的层面上进行分类和敏感性分配
• 必须执行MAC保证以确保对象的分类处于适当的级别。

基于权限的访问控制

基于权限的访问控制中的关键概念是将应用程序操作抽象为一组权限。权限可以被简单地表示为一个基于名称的字符串，例如“读”。通过检查当前用户是否具有与所请求的应用程序动作相关联的许可来做出访问决定。

用户和许可之间关系可以通过创建用户和权限（称为间接关系满足许可）来表示。在间接模型中，权限授予是指中间实体，例如用户组。当且仅当用户从用户组继承权限时，才将用户视为用户组的成员。间接模型可以更轻松地管理大量用户的权限，因为更改分配给用户组的权限会影响用户组的所有成员。

在一些基于权限的提供细粒度域对象级访问控制的访问控制系统中，可以将权限分组到类中。假设系统中的每个域对象可以与确定与相应域对象的许可的类关联。在这样的系统中，可以用权限“READ”，“WRITE”和DELETE“定义”DOCUMENT“类;可以用权限”START“，”STOP“和”REBOOT“定义”SERVER“类。

访问控制验证要求

描述
验证最小特权的原则：用户应仅能够访问函数、数据文件、URL、控制器、服务和其他资源，它们处理特定的授权，它们使应用程序免受欺骗和提权。
验证对敏感记录的访问是否实施了保护措施，这样只有授权的对象或数据才允许访问（例如：防止用户篡改参数或更改其它用户账户）
验证目录遍历是禁用的，除非故意为之。此外应用程序不应允许发现或泄露文件或目录元数据，例如：Thumbs.db、.DS_Store、.git或.svn
验证访问控制是否以安全的方式显示失败处理。
验证表示层访问控制规则是否在服务器端强制执行。
验证访问控制使用的所有用户和数据属性、策略信息不能被终端用户操纵，除非特别授权。
验证是否存在集中化机制（包括调用外部授权服务的库），以保护对每种受保护资源的访问。
验证是否可以记录所有访问控制决定，并记录所有失败的决定。
验证应用程序或框架是否使用强大的随机数（抵御CSRF令牌）或具有其他事务处理保护机制。
验证系统能抵御对安全功能、资源或数据的持续访问。例如，考虑使用资源治理器来限制每小时编辑的数量，或阻止整个数据库被单个用户独占。
验证应用程序是否具有针对较低价值系统的额外授权（例如，升级或自适应认证）或高价值应用程序的职责隔离，以根据应用程序和过去欺诈的风险执行反欺诈控制。
验证应用程序是否正确强制执行了上下文相关的授权，以进制通过参数篡改进行未授权的操作。