学习笔记-Web安全访问控制及权限提升漏洞

  • A+

什么是访问控制?

通常应用程序首先验证用户身份(账号密码登录),随后确认后续请求是否由该用户发出(会话管理),然后判断是否允许用户执行“所请求的操作”或访问"所请求的资源"(访问控制)

从用户角度访问控制模型的分为以下类型:
* 垂直访问控制:控制不同权限等级的用户访问应用程序不同的功能;如“管理员”可以修改/删除账号,而普通账号无法操作。
* 水平访问控制:控制用户只能访问自己的资源,而不能访问其他用户相同类型的资源;如“银行程序用户只能从自己的账号进行付款,而不能查看其他用户的账户”。
* 上下文相关的访问控制:防止用户以错误的顺序执行操作。如零售网站阻止用户付款后,修改订单信息。

出现访问控制漏洞的原因:
理论上应用程序需要对每一个请求,以及特定用户在特定时刻的每一项操作,都需要进行访问控制检查,由于该策略是由人定义,所以常常出现安全问题。

111.png

访问控制漏洞

应用程序允许攻击者执行某种攻击者没有权限执行的操作,就会出现访问控制漏洞。
三种访问控制模型分别对应着“垂直权限提升”、“水平权限提升”、“多步骤访问控制”的三种漏洞,并且这些漏洞之间没有明确界限。按照漏洞的表现形式和检测方法的差异会分为很多不同的类型:未受保护的功能、基于标识符的访问控制、基于多步骤的访问控制漏洞、IDOR、不安全的访问控制机制、访问控制绕过漏洞等。

漏洞实例

未受保护的功能

描述
应用程序对敏感功能没有任何访问控制,而是依赖URL的隐蔽性和不可猜测进行访问控制;如:管理用户的后台页面包含各种管理功能,而开发人员认为用户登陆后看不到后台页面,因此任务安全。但是功能链接可能在其他公开位置(如:robots.txt文件)或url爆破或JS、html和CSS源代码中找到。
造成垂直权限提升漏洞

实例1:通过robots.txt文件找到后台链接

图片.png

图片.png

实例2:网站通过对管理员页面进行了复杂命名,无法通过猜测和爆破发现,但是在响应消息中发现该URL。

图片.png

基于标识符(参数)的访问控制

描述
某些应用程序可能利用参数的不可预测性,例如将用户身份标识uid设置为无法猜测的随机值;但是该uid可能会在应用程序中公开,如“评论”、“用户消息”等位置。

造成水平权限提升漏洞

实例1:更换用户身份标识的参数
用户通过以下URL访问账户页面https://insecure-website.com/myaccount?id=123、https://ac161fa11e6ee89a80855e0a00b200c2.web-security-academy.net/my-account?id=carlos
如果用户通过将id变更,可能会访问到其他另一个用户的账户页面

首先抓取用户查询key的请求

图片.png
在网站的响应页面中找到了其他用户的id

图片.png
替换id即可越权查看该用户的KEY

造成垂直权限提升漏洞

应用程序在登录时确定用户的访问权限或角色,然后将其存储在用户可控制的位置(如:隐藏字段、cookie或预设查询字符串、响应内容),应用程序根据提交的值做出访问控制。攻击者能够修改标识访问权限或角色的参数进行权限提升。

实例1:攻击者可以修改url中的参数(其标识用户或其权限)。
https://insecure-website.com/login/home.jsp?admin=true
https://insecure-website.com/login/home.jsp?role=1

实例2:攻击者可以修改cookie中的参数(其标识用户或其权限)。
直接请求管理页面失败

图片.png
尝试将cookie中的参数进行变更

图片.png
成功绕过访问控制

图片.png

实例3:攻击者分析响应可发现权限配置参数(其标识用户或其权限),并将其添加到修改请求中。
查看响应中包含用户的其他信息

图片.png
尝试提交该请求,失败

图片.png
尝试多个参数同时提交,成功越权

图片.png

造成水平-垂直权限提升

实例1:修改标识用户身份的参数为管理员
攻击者可以使水平权限提升漏洞转变为垂直权限提升漏洞,如“https://insecure-website.com/myaccount?id=456“变更id参数,能够访问其他用户的账户页面,如果通过将id变更为管理员,获取管理员账户的访问权限。

图片.png

基于多步骤的访问控制漏洞

简述
应用的有业务可能会涉及到多步骤,如:(1)加载包含用户详细信息表单、(2)提交修改、(3)查看更改并确认修改,网站可能对其中某些步骤进行了严格访问控制,但是忽略了一个步骤就会出现漏洞。

实例1:
使用高权限账户抓取多步骤的全过程:

图片.png
使用低权限用户访问这2个请求,发现第二个阶段可以越权访问。

不安全的直接对象引用IDOR

简述
当应用程序使用用户提交的数据直接访问对象时,就可能出现IDOR漏洞。攻击者通过变更引用的对象进行攻击。
直接引用数据库对象的IDOR漏洞

实例1:
如果网站从数据库中查询客户信息的URL如下:https://insecure-website.com/customer_account?customer_number=13235
攻击者可以变更customer_number的值,绕过访问控制查看其他客户信息,造成权限提升漏洞。

直接引用静态文件的IDOR漏洞

敏感信息位于服务器端的静态资源中,容易出现IDOR漏洞。
实例1:攻击者通过修改静态文件ID,越权获取其他信息

图片.png

直接引用方法的IDOR漏洞

应用程序的API的URL和参数被泄露,或方法名可猜测,可能出现直接引用方法的IDOR漏洞。
实例1:
系统某些API的URL:http://wahh-app.com/public/securityCheck/getCurrentUserRoles
如果系统除对getCurrentUserRoles方法外,其他方法没有访问控制,就会出现安全风险。如(getAllUserRoles、getAllRoles和getAllusers等)

不安全的访问控制机制

基于referfer的访问控制漏洞

有些应用程序基于referer(标识http请求发起的网页url)进行访问控制,由于该参数客户端可控制就会出现漏洞。
实例1:
网站管理后台"/admin"进行了严格的访问控制,但是管理后台的子页面如“/admin/deleteuser”仅校验了referer是否包含"/admin"路径,就会出现漏洞。

基于地理位置的访问控制漏洞

有些网站对用户的地址位置进行访问控制。攻击者可以通过VPN、web代理绕过限制。

访问控制阻断机制错误漏洞

访问控制阻断所产生的重定向页面,可能就包含越权访问的信息。

实例1:越权阻断响应中包含敏感信息
以下请求会被JS重定向,但是源代码中还是泄露了越权信息。

图片.png

访问控制绕过漏洞

基于HTTP方法和覆盖路径的绕过方式

应用程序对用户角色访问的url和http方法实施访问控制,如:DENY: POST, /admin/deleteUser, managers,即拒绝managers角色用户使用post方法访问/admin/deleteUser路径。
一些web框架支持非标准HTTP头,使用X-Original-URL和X-Rewrite-URL可覆盖原始中的URL能够绕过前端控件的访问控制。
一些网站支持其他http请求方法,因而攻击者能够绕过前端控件的访问控制。

实例1:攻击者使用X-Original-URL覆盖url中的路径。
直接请求发现,被拦截

图片.png
使用X-Original-URL覆盖url的路径后成功越权

图片.png
实例2:攻击者使用修改HTTP方法
使用administrator用户操作,并抓取修改wiener用户权限的请求

图片.png
使用wiener用户发起请求失败

图片.png
修改HTTP请求方法,成功绕过

图片.png

参考文章:

*黑客攻防技术宝典-Web实战篇(第2版)-攻击访问控制
访问控制和权限提升https://portswigger.net/web-security/access-control

相关推荐: 记一次内网实战之不会免杀(上)

前段时间看了一下内网渗透,所以想找个环境练习一下,恰好有个兄弟丢了个站点出来,一起“练习内网”,然后就开始了“实战代练”。由于“懒”,所以记录时间和截图有些是补的。 0x00 外网入口点 打开站点(这里用baidu.com替代)看了看,左翻翻右翻翻能看到很明显…