Access-Control

# 访问控制

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

从用户角度访问控制模型分为以下类型：

垂直访问控制：控制不同权限等级的用户访问应用程序不同的功能；如 “管理员” 可以修改 / 删除账号，而普通账号无法操作。
水平访问控制：控制用户只能访问自己的资源，而不能访问其他用户相同类型的资源；如 “银行程序用户只能从自己的账号进行付款，而不能查看其他用户的账户”。
上下文相关的访问控制（多步骤）：防止用户以错误的顺序执行操作；如 “零售网址阻止用户付款后，修改订单信息” 等逻辑顺序。

身份验证确认用户是他们所说的人。
会话管理可识别同一用户正在发出哪些后续 HTTP 请求。
访问控制确定是否允许用户执行他们尝试执行的操作。

# Lab–PortSwigger_Access-Control

# 垂直权限提升

主要是拿到管理员权限，如果用户可以访问不允许他们访问的功能，则这是垂直权限提升。例如，如果非管理用户可以访问管理页面，他们可以在其中删除用户帐户，则这是垂直权限提升。

# 1. `robots.txt` 泄露未授权访问页面

然后直接访问 /administrator-panel

robots.txt 文件规定了搜索引擎抓取工具可以访问您网站上的哪些网址。此文件主要用于避免您的网站收到过多请求；它并不是一种阻止 Google 抓取某个网页的机制。

如果可以访问到网站的 robots.txt ，就可以直接看到网站的部分目录

# 2. `JS` 文件暴露未授权访问页面

通过 F12 查看 js 代码，有时会发现敏感页面

然后直接访问

贴一个工具 JSSCAN :

# 3. 参数控制的访问权限

某些应用程序在登录时确定用户的访问权限或角色，然后将此信息存储在用户可控制的位置。这可能是：

一个隐藏的字段。
Cookie。
预设查询字符串参数。

应用程序根据提交的值做出访问控制决策。例如：

https://insecure-website.com/login/home.jsp?admin=true https://insecure-website.com/login/home.jsp?role=1

这种方法是不安全的，因为用户可以修改他们无权访问的值和访问功能，例如管理功能。

先登录普通用户，发现一个 Admin 参数控制是否是管理员：

登录普通用户之后，访问管理员页面，将 Admin 改为 true 即可访问：

# 4. 响应包参数控制的访问权限

一些访问控制的参数有时候可能不在登录处或者访问敏感页面处，而是在更新一些个人信息的时候。

比如在更改个人邮箱处，以 json 传输数据：

查看响应包可看到敏感参数 roleid，猜测其是控制权限的参数：

在请求头中加入 roleid，达到覆盖参数的效果：

# 5. Header 头中 X-Original-URL 参数控制的访问权限

某些应用程序框架支持各种非标准 HTTP 标头，这些标头可用于覆盖原始请求中的 URL，例如和。如果网站使用严格的前端控件来限制基于 URL 的访问，但应用程序允许通过请求标头覆盖 URL，则可以使用如下请求绕过访问控制： X-Original-URL``X-Rewrite-URL

POST / HTTP/1.1 
X-Original-URL: /admin/deleteUser

改变参数 X-Original-URL: /admin 即可访问特定的未授权页面：

# 6. 受请求方法控制的访问权限

另一种攻击与请求中使用的 HTTP 方法有关。前面部分中介绍的前端控件根据 URL 和 HTTP 方法限制访问。某些网站在执行操作时允许不同的 HTTP 请求方法。如果攻击者可以使用 GET （或其他）方法对受限制的 URL 执行操作，则可以绕过在平台层实现的访问控制

再登陆普通用户 wiener 拿到 session

将 session 复制替代前面提权的 session

提示未授权，

尝试将请求方法改为 POSTX，提示缺少参数 username：

说明更改请求方式可以控制访问的权限，继续将请求方法改为 GET：

# 7. 于 URL 匹配差异导致的访问控制中断

网站在将传入请求的路径与定义的终结点的匹配程度上可能会有所不同。例如，它们可能容忍不一致的大小写，因此对的请求可能仍映射到终结点。如果访问控制机制的容忍度较低，它可能会将它们视为两个不同的终结点，并因此无法强制实施正确的限制。 /ADMIN/DELETEUSER /admin/deleteUser

如果使用 Spring 框架的开发人员启用了该选项，也会出现类似的差异。这允许将具有任意文件扩展名的路径映射到没有文件扩展名的等效终结点。换言之，请求仍将与模式匹配。在 Spring 5.3 之前，默认情况下启用此选项。 useSuffixPatternMatch /admin/deleteUser.anything /admin/deleteUser

在其他系统上，可能会遇到是否被视为不同终结点的差异。在这种情况下，可以通过在路径上追加尾部斜杠来绕过访问控制。 /admin/deleteUser /admin/deleteUser/

# 水平权限提升

如果用户能够访问属于其他用户的资源，而不是他们自己的该类型的资源，则会发生水平权限提升。例如，如果员工可以访问其他员工以及他们自己的记录，则这是横向权限提升。

手法与垂直提权相似

# 7. 控制 userID 的水平越权

直接更改 URL 的 id 拿到 api key

# 8. 随机 userID 控制的水平越权

在某些应用程序中，可利用的参数没有可预测的值。例如，应用程序可能使用 ** 全局唯一标识符（GUID） ** 来标识用户，而不是递增数字。这可以防止攻击者猜测或预测其他用户的标识符。但是，属于其他用户的 GUID 可能会在引用用户的应用程序中的其他位置（例如用户消息或评论）中公开。

就如这个，id 是随机生成的 uuid，枚举爆破肯定是行不通的

找到 carlos 发表的文章尝试获取 userid

复制到 URL：

# 9. 存在于重定向之前的页面中 userID

在某些情况下，应用程序会检测到不允许用户访问资源的时间，并返回到登录页的重定向。但是，包含重定向的响应可能仍包含属于目标用户的一些敏感数据，因此攻击仍然成功。

像这样，直接改 URL 里的 id 会重定向为登陆界面，但是在重定向之前的相应包中，仍存在该用户的信息

# 水平到垂直权限提升

通常，通过损害特权更高的用户，可以将水平权限提升攻击转变为垂直权限提升。例如，水平升级可能允许攻击者重置或捕获属于其他用户的密码。如果攻击者以管理用户为目标并破坏其帐户，则他们可以获得管理访问权限，从而执行垂直权限提升。

# 10. userID 控制的垂直越权

直接在 YRL 中改 id：

就拿到了管理员密码

# 11. 不安全的直接对象引用（IDOR）

直接引用数据库对象的 IDOR 漏洞

假设一个网站使用以下 URL 通过从后端数据库检索信息来访问客户帐户页面：

https://insecure-website.com/customer_account?customer_number=132355

在这里，客户编号直接用作在后端数据库上执行的查询中的记录索引。如果没有其他控制措施，攻击者只需修改 customer_number，绕过访问控制即可查看其他客户的记录。这是导致水平权限升级的 IDOR 漏洞的示例。``

攻击者可能能够通过在绕过访问控制的同时将用户更改为具有额外权限的用户来执行水平和垂直权限提升。例如，其他可能性包括利用密码泄漏或在攻击者登陆用户帐户页面后修改参数。

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

当敏感资源位于服务器端文件系统的静态文件中时，通常会出现 IDOR 漏洞。例如，网站可能会使用递增的文件名将聊天消息脚本保存到磁盘，并允许用户通过访问如下所示的 URL 来检索这些脚本：

https://insecure-website.com/static/12144.txt

在这种情况下，攻击者只需修改文件名即可检索其他用户创建的脚本，并可能获取用户凭据和其他敏感数据。

# 常规 IDOR

通过查看聊天记录，可发现 web 通过 GET 请求下载了聊天记录：

服务端未对 GET 请求的参数进行权限的校验，造成了敏感聊天记录的泄露。

将 GET 的地址可更改到 /download-transcript/1.txt ：

# 用户注册处的 IDOR

在网站注册功能中发起数据包拦截，目标网站调用了一个账户注册 API，Burp 捕获的账户注册请求数据包如下：

POST /analytics/index.php/plus/registerportal?user_id=43657&key=344246b382b1d70c25ea14ed6f2760c6 HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 239
Host: api.***.com
Connection: close
Accept-Encoding: gzip, deflate
User-Agent: okhttp/3.4.1
email=test@***.com&password=as&username=&firstname=tvbb&lastname=gvcz&mobile=&country=test&city=hfhdggd&birthday_full=&gender=fknefjn

可以看到，在上述数据包的 POST 操作中包含了 user_id 参数，我们把它修改为其它字符串随机值，然后服务端响应回来的消息中有了这样的提示：用户已经存在！更为重要的是，服务端响应回来的信息中包含了与该注册用户相关的姓名、邮箱、联系地址等等：

HTTP/1.1 200 OK
Date: Tue, 05 Mar 2019 12:53:30 GMT
Content-Type: text/html
Connection: close
Set-Cookie: __cfduid=dc4d54bb59b5c4a2c8501e3ed1cd5952b1551790409; expires=Wed, 04-Mar-20 12:53:29 GMT; path=/; domain=.whocare.com; HttpOnly
Vary: Accept-Encoding
Server: cloudflare
CF-RAY: 4b2c3badddb3ce21-LHR
Content-Length: 311
{"error":"exist","user":[{"id":"34666","username":"admin","firstname":"Pappu","lastname":"Rahul","email":"admin@***.com","mobile":null,"gender":"male","birthday":null,"country":"","city":null,"address":null,"address1":[Reducted],"postcode":[Reducted],"ip_address":[Reducted],"app_id":[Reducted]}]}

而且通过这样，甚至可以通过暴力枚举用户参数 user_id，大量获取目标网站用户信息，当然其中也会包含管理员信息。

# 邮件订阅中的 IDOR

一些网站为用户提供了一个订阅选项，可以通过用户邮件方式获取一些网站的最新资讯。而在用户设置面板中，存在一个订阅取消按钮，当点击该按钮之后，它会向注册用户发送一个取消订阅的通知链接，URL 如下：

http://***.com/deleteNewsletter/dGVzdGVybWFpbEBnbWFpbC5jb20=

仔细看可知道，它结尾包含了一个 base64 编码的字符串，解密后

dGVzdGVybWFpbEBnbWFpbC5jb20  =>  testermail@gmail.com

这里看似这种动作未对请求做身份校验，所以，在此我们需要其他注册用户的绑定邮箱来进行测试，看看是否能对其他注册用户执行订阅取消操作。

这里的一种攻击可能性为：我们要以收集大量目标网站注册用户的邮箱，然后分别把它们进行 base64 编码，形成字典，放到 Burp 的 Intruder 模块中，进行自动化攻击测试，这样一来，就形成了对批量用户的订阅取消动作。这里可以综合利用上述的注册处 IDOR 漏洞来形成更大的威胁。

# 意见反馈中的 IDOR

如果用户向目标网站提交意见反馈（Feedback）的数据包如下：

POST /Services/PostContactUsEmail HTTP/1.1
Host: www.***.com
Connection: close
Content-Length: 327
Accept: */*
Origin: https://www.***.com
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: https://www.***.com/feedback
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: ******
ContactUs_Name_Txt=hiname&ContactUs_Email_Txt=attacker@gmail.com&ContactUs_MessageType_Txt=%D8%A7%D8%B3%D8%AA%D9%81%D8%B3%D8%A7%D8%B1&ContactUs_Department_Txt=feedback@***.com%23%D8%A7%D9%84%D8%AF%D8%B9%D9%85+%D8%A7%D9%84%D9%81%D9%86%D9%8A&ContactUs_MessageBody_Txtthis+is+the+comment&ContactUs_Captcha_Txt=QBAQLU

仔细看其中提交的参数，它包含了以下几个重要信息：

ContactUs_Department_Txt = 将会收到反馈意见的邮箱地址

ContactUs_Email_Txt = 当前用户用来发送反馈意见的邮箱地址

ContactUs_MessageBody_Txt = 用户发送的反馈意见信息

上面有两个地方的邮箱地址我们可以进行修改，那就是：

ContactUs_Department_Txt = admin@***.com

ContactUs_Email_Txt = 任何你想发送邮件的用户邮箱地址，或者恶意一点，把它设为网站所有用户邮箱地址。

这样一来，所有网站用户都会收到一封来自管理员邮箱的邮件，这可以用来作为钓鱼攻击的一个切入点。

# 12. Step 被跳过的访问控制漏洞

许多网站通过一系列步骤实现重要功能。这在以下情况下很常见：

需要捕获各种输入或选项。
在执行操作之前，用户需要查看并确认详细信息。

例如，更新用户详细信息的管理功能可能涉及以下步骤：

加载包含特定用户详细信息的表单。
提交更改。
查看更改并确认。

有时，网站会对其中一些步骤实施严格的访问控制，但会忽略其他步骤。想象一下，在一个网站上，访问控制正确地应用于第一步和第二步，而不是第三步。该网站假设用户只有在已经完成了正确控制的第一步时才会到达第 3 步。攻击者可以通过跳过前两个步骤并直接提交带有所需参数的第三步请求来获得对该函数的未经授权的访问。

先记录两个操作的数据包

再登录 wiener 拿到 session，将 session 复制到第二个包，并修改 username

# 13. Referer 控制的访问权限

某些网站基于在 HTTP 请求中提交的标头进行访问控制。浏览器可以将标头 Referer 添加到请求中，以指示哪个页面发起了请求。

例如，应用程序强势地对位于 /admin 的主管理页面实施访问控制，但对于子页面 /admin/deleteUser ，例如 Referer 仅检查标题。如果 Referer 标头包含主 URL，则允许请求 /admin 。

在这种情况下，攻击者可以完全控制 Referer 标头。这意味着他们可以通过 Referer 提供所需的标题来伪造对敏感子页面的直接请求，并获得未经授权的访问。

依然保存管理员提升权限的两个包，登录 wiener 拿到 session，带入包修改权限

并更改 Referer 参数为：

https://ac001fcd1f55c21580c43667006f0016.web-security-academy.net/admin

Fc04dB's BLOG