失效的访问控制

Posted Flytiger1220

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了失效的访问控制相关的知识，希望对你有一定的参考价值。

失效的访问控制

这是我在OWASP上几篇文章翻译整理加删减总结出的一个关于失效的访问控制的检查可解决的文章。勉强算个原创吧。

由于缺乏自动化的检测和应用程序开发人员缺乏有效 的功能测试，因而访问控制缺陷很常见。导致攻击者可以冒充用户、管理员或拥有特权的用户，或者创建、访问、更新或删除任何记录。

出现的问题

文件包含/目录遍历

许多web应用使用文件管理作为它们日常操作的一部分。但他们使用没有被好好设计的输入验证方法，攻击者可以利用（这个漏洞）来修改或写入文件，甚至执行任意代码。

传统的web服务器和web应用程序用身份验证来控制文件资源访问。web服务器尝试将用户的文件限制在“根目录”或“web文档根”中，后者标识文件系统层面的物理目录。用户必须将此目录十位web应用程序层次结构的基本目录。

许多web应用程序使用服务器端脚本来包含不同类型的文件。如管理图像，模板，加载静态文本等，但如果未正确验证输入参数（如表单，cookie）这些程序会暴露安全漏洞。这种问题出现在路径遍历/文件包含攻击中。通过利用此类漏洞，攻击者能读取它们通常无法读取的目录或文件，访问web文档根目录之外的数据，或包含来自外部网络的脚本或其他类型文件。

如臭名昭著的%5c 暴库或dot-dot-slash （../）目录遍历，目录爬升或回溯。

例子

http://example.com/getUserProfile.jsp?item=ikki.html 
http://example.com/getUserProfile.jsp?item=../../../../etc/passwd
  
  
  • 若getUserProfile.jsp是从文件加载静态信息并向用户显示，如果在访问控制不理想的情况下，攻击者可以构造相对路径，读取etc/passwd的文件内容。
     

   
    其他地方也可能有类似漏洞如cookie：
     

   
    Cookie：USER = 1826cc8f：PSTYLE = GreenDotRed
Cookie：USER = 1826cc8f：PSTYLE = .. / .. / .. / .. / etc / passwd
    
    
       

   
      也可能包含外部网站的文件：
       

   
      http://example.com/index.php?file=http://www.owasp.org/malicioustxt
    
    
         

   
        如果可接受协议类参数，也可以构造如下攻击：
         

   
        http://example.com/index.php?file=file:///etc/passwd
    
    
           

   
          或探测本地服务：
           

   
          http://example.com/index.php?file=http://localhost:8080或http://example.com/index.php?file=http://192.168.0.2:9080
    
    
             

   
            甚至可以不使用任何目录遍历字符开显示CGI组件源代码：
             

   
            http://example.com/main.cgi?home=main.cgi
    
    
               

   
              main.cgi的组件和普通html静态文件在同一个目录中，在某些情况下，攻击者使用. %00 null等的编码可以绕过扩展名校验。
               

   
              关于不同操作系统的路径分隔符
               

   
              Linux
根目录：“/” 
目录分隔符：“/”
Windows
根目录：“<驱动器号>：\\”   
目录分隔符：“\\”或“/”
Mac OS
根目录：“<驱动器号>：” 
目录分隔符：“：”
    
    
                 

   
                url编码与双url编码绕过：
                 

   
                ％2e％2e％2f 表示 ../
％2e％2e / 表示 ../ 
..％2f 表示 ../
％2e％2e％5c 表示 .. \\ 
％2e％2e \\ 表示 .. \\ 
..％5c 代表 .. \\ 
％252e％252e％255c 代表 .. \\ 
..％255c 代表 .. \\等等。
    
    
                   

   
                  Unicode/UTF-8编码绕过
                   

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

   
                    Windows shell中，解析文件非常灵活，如以下任何内容附加到shell命令中使用的路径会导致函数没有区别： 
                     

   
                    • 路径末端的尖括号“>”和“<”
                    • 在路径末尾双引号（正确关闭）
                    • 无关的当前目录标记，例如“./”或“。\\”
                    • 具有可能存在或可能不存在的任意项的无关父目录标记
                     

   
                    -  file.txt 
-  file.txt ... 
-  file.txt <spaces> 
-  file.txt“”“” 
-  file.txt <<< >>> < 
-  ./././file.txt 
- nonexistant / ../file.txt
    
    
                       

   
                      在任何shell命令或API调用中使用时，下面的符号会被丢弃，其中字符串被视为文件名：
                       

   
                      句号
空格
    
    
                         

   
                        Windows UNC文件路径：用于引用SMB共享上的文件。有时，可以使应用程序引用远程UNC文件路径上的文件。如果是这样，Windows SMB服务器可能会将存储的凭据发送给攻击者，攻击者可以捕获并破解。这些也可以与自引用IP地址或域名一起使用来逃避过滤器，或者用于访问攻击者无法访问的SMB共享上的文件，但可以从Web服务器访问。 
                         

   
                        \\\\ server_or_ip \\ path \\ to \\ file.abc 
\\\\？\\ server_or_ip \\ path \\ to \\ file.abc
    
    
                           

   
                          Windows NT设备命名空间：用于指代Windows设备命名空间。某些引用将允许使用不同的路径访问文件系统。
                           

   
                          • 可能相当于驱动器号，例如c：\\，甚至是没有指定字母的驱动器卷。
                             
                            \\\\.\\GLOBALROOT\\Device\\HarddiskVolume1\\
      
      
                            • 1
                          • 指机器上的第一个光盘驱动器。
                             
                            \\\\.\\CdRom0\\
      
      
                             

   
                            权限绕过（水平越权）
                             

   
                            用户未经过身份验证访问资源，或注销后仍可访问资源，对不同用户访问的资源没有做很好的校验，如标准用户可访问管理员资源，或访问其他用户私有资源等。
                             

   
                            例子
                             

   
                            下面例子的url是管理员彩蛋的一部分：
                             

   
                             https://www.example.com/admin/addUser.jsp 
    
    
                               

   
                              访问这个页面你的HTTP请求如下：
                               

   
                              POST /admin/addUser.jsp HTTP/1.1
Host: www.example.com
[other HTTP headers]

                            userID=fakeuser&role=3&group=grp001

                              如果一个非管理员用户发送这个请求到服务器，会执行什么操作，在权限验证和访问控制不理想的情况下，非管理员用户通过构造管理员相应操作的数据包，也能达到管理员的权限。如增加/删除用户等。

                              权限提升（垂直越权）

                              权限提升是指用户权限从一个阶段提升到另一个阶段的问题，当用户访问的资源比通常情况下访问到的资源更多时，就发生了权限提示漏洞，应用程序应该阻止该权限提升或更改。权限提升一般是由于应用程序自身的缺陷引起的，最后导致程序执行的操作拥有比开发人员或系统管理员预期更多的权限。

                              例子

                              下面的HTTP POST请求允许属于grp001的用户访问#0001订单：

                               POST /user/viewOrder.jsp HTTP/1.1
 Host: www.example.com
 ...

                              groupID=grp001&orderID=0001

                                如果对权限的校验不正常的情况，一个不属于grp001的用户修改groupID参数也可获得查看#0001的权限。

                                操纵用户配置权限：下面服务器的响应显示校验成功后返回给用户的HTML中的隐藏字段。

                                HTTP/1.1 200 OK
Server: Netscape-Enterprise/6.0
Date: Wed, 1 Apr 2006 13:51:20 GMT
Set-Cookie: USER=aW78ryrGrTWs4MnOd32Fs51yDqp; path=/; domain=www.example.com 
Set-Cookie: SESSION=k+KmKeHXTgDi1J5fT7Zz; path=/; domain= www.example.com
Cache-Control: no-cache
Pragma: No-cache 
Content-length: 247
Content-Type: text/html
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Connection: close

                                <form name=“autoriz” method=“POST” action = “visual.jsp”>
                                <input type=“hidden” name=“profile” value=“SysAdmin”>
                                <body onload=“document.forms.autoriz.submit()”>
                                </td>
                                </tr>

                                  如果我们将profile改为”SysAdmin”，可能会变成管理员。

                                  操纵条件值：在服务器发送错误消息时，该消息包含在一组相应代码中的特定参数中，如：

                                  @0`1`3`3``0`UC`1`Status`OK`SEC`5`1`0`ResultSet`0`PVValid`-1`0`0` Notifications`0`0`3`Command  Manager`0`0`0` StateToolsBar`0`0`0`    
StateExecToolBar`0`0`0`FlagsToolBar`0

                                    如果我们将“PVValid”从-1改为0，那可能代表没有错误，从而通过管理员身份验证

                                    操纵IP地址：某些网站使用IP地址来限制访问或根据IP地址计算错误登录次数，如：

                                    X-Forwarded-For: 8.1.1.1

                                      如果可以修改X-Forwarded-For就可以绕过这种检验

                                      URL遍历：尝试遍历网站查看是否有页面漏掉权限检验

                                      /../.././userInfo.html

                                        弱SessionID：

                                        若SessionID加密算法很弱，或使用有规律的算法，可能会被攻击者猜到或解密，造成越权。

                                        不安全直接对象的引用

                                        当应用程序根据用户提供的输入提供对对象的直接访问时，会发生不安全的直接对象引用。 攻击者可以直接绕过授权并访问系统中的资源，例如数据库记录或文件。

                                        由于应用程序获取用户提供的输入并使用它来检索对象而不执行足够的授权检查。不安全的直接对象引用允许攻击者通过修改用于直接指向对象的参数值来直接绕过授权和访问资源。这些资源可以是属于其他用户的数据库条目，系统中的文件等。

                                        例子

                                        参数值直接用于数据库检索：

                                        http://foo.bar/somepage?invoice=12345

                                          参数invoice的值直接进入发票数据库检索，并将结果显示，如不对检索对象进行校验，那么攻击者可以遍历发票编号造成信息泄露。

                                          参数值直接在系统中操作：

                                          http://foo.bar/changepassword?user=someuser

                                            user参数值用于告诉应用程序用户访问哪个功能，若没有对用户本身作出限制，那么用户修改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令牌）或具有其他事务处理保护机制。
                                            验证系统能抵御对安全功能、资源或数据的持续访问。例如，考虑使用资源治理器来限制每小时编辑的数量，或阻止整个数据库被单个用户独占。
                                            验证应用程序是否具有针对较低价值系统的额外授权（例如，升级或自适应认证）或高价值应用程序的职责隔离，以根据应用程序和过去欺诈的风险执行反欺诈控制。
                                            验证应用程序是否正确强制执行了上下文相关的授权，以进制通过参数篡改进行未授权的操作。

                                            以上是关于失效的访问控制的主要内容，如果未能解决你的问题，请参考以下文章

                                            owasptop10

                                            黑客攻防技术宝典web实战篇：攻击访问控制习题

                                            高并发下缓存失效问题及解决方案

                                            高并发下缓存失效问题及解决方案

                                            构建ROP链实现远程栈溢出

                                            XSS 不鸽的话可能会有