导读：
面向读者：对于网络安全方面的学者。
本文知识点（读者自测）：
（1）纵向权限提升、不受保护的功能、基于参数的访问控制方法、平台配置错误导致访问控制中断、横向权限提升（√）
（2）、横向到纵向权限提升、不安全的直接对象引用、、多步骤流程中的访问控制漏洞、基于引用的访问控制、基于位置的访问控制（√）
现在只对常读和星标的公众号才展示大图推送，建议大家能把渗透安全团队“设为星标”，否则可能就看不到了啦！
目录
一、访问控制
1、定义：
2、危害
3、垂直访问控制
4、水平访问控制
5、上下文相关的访问控制
二、破坏访问控制的示例
1、纵向权限提升
2、不受保护的功能
实验1：不受保护的管理功能
实验2：不受保护的管理功能，URL不可预测
3、基于参数的访问控制方法
实验3：由请求参数控制的用户角色
实验4：可以在用户配置文件中修改用户角色
4、平台配置错误导致访问控制中断
实验10：可以绕过基于URL的访问控制
实验11：可以绕过基于方法的访问控制
5、横向权限提升
实验5：由请求参数控制的用户ID
实验6：用户ID由请求参数控制，用户ID不可预测
实验7：用户ID由请求参数控制，重定向时发生数据泄漏
6、横向到纵向权限提升
实验8：用户ID由密码泄露的请求参数控制
7、不安全的直接对象引用
实验9：不安全的直接对象引用
8、多步骤流程中的访问控制漏洞
实验10：多步骤流程，其中一个步骤没有访问控制
9、基于引用的访问控制
实验11：基于引用的访问控制
10、基于位置的访问控制
1、定义：
1、访问控制（或授权）是对谁可以执行尝试的操作或访问他们请求的资源施加约束。在Web应用程序的上下文中，访问控制取决于身份验证和会话管理：
（1）身份验证可识别用户并确认他们的身份
（2）会话管理标识该用户正在发出哪些后续HTTP请求
（3）访问控制确定是否允许用户执行他们尝试执行的操作2、危害
1、破坏访问控制是一种常见的安全漏洞，通常是严重的安全漏洞。访问控制的设计和管理是一个复杂的动态问题，它将业务、组织和法律的约束应用于技术实现。访问控制设计决策必须由人而不是技术来做出，并且出错的可能性很高。
2、从用户的角度来看，访问控制可分为：垂直访问控制、水平访问控制、上下文相关的访问控制
3、垂直访问控制
1、原理：垂直访问控制是限制对其他类型用户不可用的敏感功能的访问的机制。
————
2、危害：利用垂直访问控制，不同类型的用户可以访问不同的应用程序功能。如管理员可以修改或删除任何用户的帐户，而普通用户则无权执行这些操作。垂直访问控制可以是安全模型的更细粒度的实现，这些安全模型被设计用于强制执行业务策略，如职责分离和最小特权。
4、水平访问控制
1、原理：水平访问控制是将对资源的访问限制到被特别允许访问那些资源的用户的机制。
————
2、危害：通过水平访问控制，不同的用户可以访问同一类型的资源子集。例如，银行应用程序将允许用户查看交易并从自己的帐户进行支付，但不允许任何其他用户的帐户。
5、上下文相关的访问控制
1、原理：上下文相关的访问控制根据应用程序的状态或用户与应用程序的交互来限制对功能和资源的访问。
————
2、危害：上下文相关的访问控制可防止用户以错误的顺序执行操作。如零售网站可能会阻止用户在付款后修改其购物车的内容。
1、纵向权限提升
如果用户可以访问不允许其访问的功能，则这是垂直权限提升。如一个非管理员用户实际上可以访问一个管理页面，在那里他们可以删除用户帐户，那么这就是垂直权限提升
2、不受保护的功能
1、最基本的情况是，当应用程序不对敏感功能实施任何保护时，会出现垂直权限提升。如管理功能可能从管理员的欢迎页面链接，而不是从用户的欢迎页面链接。然而用户可能仅仅能够通过直接浏览到相关的管理URL来访问管理功能
2、示例：
如某个网站可能在以下URL上托管敏感功能：
https://insecure-website.com/admin事实上，任何用户都可以访问该功能，而不仅仅是在其用户界面中具有指向该功能的链接的管理用户。在某些情况下，管理URL可能会在其他位置公开，如robots.txt文件：
https://insecure-website.com/robots.txt即使URL没有在任何地方公开，攻击者也可以使用单词列表强行找到敏感功能的位置
涉及实验：
实验1：不受保护的管理功能
3、隐藏的接口
在某些情况下，敏感功能没有得到可靠的保护，而是通过提供一个不可预测的URL来隐藏：所谓的模糊安全。仅仅隐藏敏感功能并不能提供有效的访问控制，因为用户仍然可能以各种方式发现模糊的URL。
如在以下URL承载管理功能的应用程序：
https://insecure-website.com/administrator-panel-yb556这可能无法被攻击者直接猜到。但应用程序仍可能将URL泄漏给用户。如URL可能在JavaScript中公开，JavaScript基于用户的角色构造用户界面：
<script>
var isAdmin = false;
if (isAdmin) {
...
var adminPanelTag = document.createElement('a');
adminPanelTag.setAttribute('https://insecure-website.com/administrator-panel-yb556');
adminPanelTag.innerText = 'Admin panel';
...
}
</script>如果用户是管理员用户，此脚本将向用户的UI添加链接。但包含URL的脚本对所有用户都可见，而不管其角色如何。
涉及实验：
实验2：不受保护的管理功能，URL不可预测
实验1：不受保护的管理功能
信息：
本实验有一个未受保护的管理面板。
通过删除用户carlos解决实验
part1：
将/robots. txt加到URL后查看robots.txt文件
Disallow行显示了管理面板的路径
part2:
在主URL后加上/administrator-panel以加载管理面板
删除carlos完成实验
实验2：不受保护的管理功能，URL不可预测
信息：
本实验有一个未受保护的管理面板。它位于一个不可预测的位置，但该位置在应用程序中的某个地方公开。
通过访问管理面板并使用它删除用户carlos来解决实验
part1：
使用Burp Suite或Web浏览器的开发工具查看实验主页的源代码。
(Ctrl+U查看源码)注意到它包含一些JavaScript，公开了管理面板的URL
会有一个是否是admin的检测
检测成功则跳转
part2:
加载管理面板并删除carlos
3、基于参数的访问控制方法
1、某些应用程序在登录时确定用户的访问权限或角色，然后将此信息存储在用户可控制的位置，如隐藏字段、cookie或预设查询字符串参数。应用程序根据提交的值做出后续访问控制决策
例如：
https://insecure-website.com/login/home.jsp?admin=true
https://insecure-website.com/login/home.jsp?role=1这种方法从根本上讲是不安全的，因为用户可以简单地修改值并获得对他们未被授权的功能（如管理功能）的访问权限
2、涉及实验：
实验3：由请求参数控制的用户角色
实验4：可以在用户配置文件中修改用户角色
实验3：由请求参数控制的用户角色
信息：
本实验在/admin下有一个管理面板，用于识别使用可伪造Cookie的管理员。
通过访问管理面板并使用它删除用户carlos来解决实验
已有账号：wiener:peter
part1:
浏览到/admin，发现您无法访问管理面板
part2:
在Burp代理监听（完整的登陆流程中，在HTTP历史记录中可以发现有一个admin身份的验证）
使用BP拦截并将cookie Admin=false改为Admin=true
（第二个跳转到/my-account的数据包）
改为true后关闭拦截，完成并提交登录页面每次点击的时候都拦截请求
每一步都要修改为true
part3:
完成实验
点击删除，然后再改为true
实验4：可以在用户配置文件中修改用户角色
信息：
本实验在/admin下有一个管理面板。只有角色标识为2的登录用户才能访问。
通过访问管理面板并使用它删除用户carlos来解决实验
已有账号：wiener:peter
part1:
使用提供的凭据登录并访问您的帐户页面
使用提供的功能更新与帐户关联的电子邮件地址(有一个更新接口，尝试更新其他内容)
更新邮箱，并查看数据包
查看返回的数据包发现我们只修改了这么多参数中的其一
part2：
将电子邮件提交请求发送到repeater重发
增加参数将”roleid“:2添加到请求正文的JSON中，响应中已变为2
part3：
完成实验
浏览到/admin并删除carlos
4、平台配置错误导致访问控制中断
1、一些应用程序通过基于用户角色限制对特定URL和HTTP方法的访问，在平台层强制执行访问控制。
如应用程序可能配置如下规则：
DENY: POST, /admin/deleteUser, managers规则拒绝访问后URL上的方法/admin/deleteUser，适用于管理员组中的用户（在这种情况下，各种事情都可能出错，导致访问控制绕过）
2、一些应用程序框架支持各种非标准HTTP头，这些头可用于覆盖原始请求中的URL
如X-Original-URL和X-Rewrite-URL如果网站使用严格的前端控制来限制基于URL的访问，但应用程序允许通过请求标头覆盖URL，则可能使用如下请求绕过访问控制：
POST / HTTP/1.1
X-Original-URL: /admin/deleteUser
...3、另一种攻击可能与请求中使用的HTTP方法有关。上述前端控件根据URL和HTTP方法限制访问。某些网站在执行操作时允许使用其他HTTP请求方法。如果攻击者可以使用GET（或其他）方法对受限URL执行操作，那么他们就可以绕过在平台层实现的访问控制。
4、涉及实验：
实验10：可以绕过基于URL的访问控制
实验11：可以绕过基于方法的访问控制
实验10：可以绕过基于URL的访问控制
信息：
此网站在/admin处有一个未经身份验证的管理面板，但前端系统已配置为阻止对该路径的外部访问。但后端应用程序构建在支持X-Original-URL标头的框架上。
要解决实验问题，访问管理面板并删除用户carlos
已有账号：wiener:peter
part1:
尝试加载/admin并观察是否被阻止
（响应非常简单，表明可能来自前端系统）
part2:
发送请求到repeater
将请求行中的URL更改为/并添加HTTP标头X-Original-URL:/invalid
注意到应用程序返回“未找到”响应(表明后端系统正在处理来自X-Original-URL头的URL)
将X-Original-URL标头的值更改为/admin，并放包
然后退回主页，现在可以访问管理页面了
part3：
要删除用户卡洛斯(可能要等很久)添加?username=carlos设置为真实的的查询字符串，并将X-Original-URL路径更改为/admin/delete
?username=carlos
X-Original-URL:/admin/delete（抓一个包修改，或者重发后刷新）
实验完成
实验11：可以绕过基于方法的访问控制
信息：
本实验部分基于HTTP请求方法实现访问控制，可以通过使用凭据administrator：admin登录来熟悉管理面板（利用有缺陷的访问控制将自己提升为管理员）
已有账号：wiener/peter
part1:
使用管理员凭据登录（administrator：admin）
浏览到管理面板，提升carlos，然后将HTTP请求发送到Burp Repeater
part2：
打开一个私有/匿名浏览器窗口，然后使用非管理员凭据登录（wiener/peter）
尝试通过将非管理员用户的会话cookie复制到现有的BurpRepeater请求中来重新提升卡洛斯，并观察到响应显示为“Unauthorized”（未经授权）
将方法从POST更改为POSTX，并观察响应更改为“missing parameter”（缺少参数）
通过右键单击并选择“更改请求方法”，将请求转换为使用GET方法
part3：
将username参数更改为我们的用户名并重新发送请求（wiener）
（如果没完成实验，就刷新一下页面）
5、横向权限提升
1、原理：当用户能够访问属于另一个用户的资源而不是他们自己的资源时，就会出现横向权限提升。如一个员工应该只能访问自己的雇佣和工资单记录，但实际上也可以访问其他员工的记录，那么这就是横向权限提升。
2、水平权限提升攻击可能使用与垂直权限提升类似的利用方法。
如用户通常可以使用如下URL访问自己的帐户页面：
https://insecure-website.com/myaccount?id=123
（如果攻击者将id参数值修改为另一个用户的值，那么攻击者就可能获得对另一个用户的帐户页面以及相关数据和函数的访问权限）涉及实验：
实验5：由请求参数控制的用户ID
3、在某些应用程序中，可利用参数不具有可预测的值。如应用程序可以使用全局唯一标识符（GUID）来标识用户，而不是使用递增的数字。在这里，攻击者可能无法猜测或预测其他用户的标识符。但属于其他用户的GUID可能会在引用用户的应用程序中的其他地方公开，例如用户消息或评论
————
涉及实验：
实验6：用户ID由请求参数控制，用户ID不可预测
4、在某些情况下，应用程序会检测到用户何时不被允许访问资源，并返回到登录页的重定向。但包含重定向的响应仍可能包含属于目标用户的某些敏感数据，因此攻击仍会成功。
————
涉及实验：
实验7：用户ID由请求参数控制，重定向时发生数据泄漏
实验5：由请求参数控制的用户ID
信息：
本实验的用户帐户页面上存在一个横向权限提升漏洞。
要解决实验问题，获取用户carlos的API密钥并将其作为解决方案提交
已有账号：wiener:peterpart1:
使用已有账号登陆
分析HTTP历史记录中数据包，无特殊参数
再次点击My account
分析数据包，URL在“id”参数中包含用户名
part2：
发送请求到repeater，将“id”参数更改为carlos
检索并提交卡洛斯的API密钥
实验6：用户ID由请求参数控制，用户ID不可预测
信息：
这个实验室在用户账户页面上有一个水平的权限提升漏洞，但是用 GUID 来识别用户
已有账号：wiener:peter
part1：
找一篇 Carlos 的博文。
单击 Carlos 并观察 URL 包含他的用户 ID。记下这个 ID。
part2:
使用已有账号登录并访问
wiener:peter
登陆后再次点击My account，分析数据包
part3：
完成实验
将“ ID”参数更改为保存的用户 ID。检索并提交 API 密钥。
如果卡住，就刷新一下页面
实验7：用户ID由请求参数控制，重定向时发生数据泄漏
该实验室包含一个访问控制漏洞，其中敏感信息在重定向响应的主体中泄露。
要解决该实验室的问题，获取用户 Carlos 的 API 密钥，并将其作为解决方案提交。
已有账号：wiener:peter
part1:
使用提供的凭据登录并访问您的帐户页面。
再次点击My account，分析数据包
发现通过参数名传参的参数
part2:
发送到bp的repeater
将“ id”参数更改为 Carlos
（虽然响应现在将重定向到主页，但是它有一个主体，其中包含属于 Carlos 的 API 密钥）
提交 API 密钥
6、横向到纵向权限提升
1、危害：一般水平权限提升攻击可以通过危害更高权限的用户而转变为垂直权限提升。如横向升级可能允许攻击者重置或捕获属于其他用户的密码。如果攻击者以管理用户为目标并危害其帐户，则他们可以获得管理访问权限，从而执行垂直权限提升。
如攻击者可能能够使用已经描述的横向权限提升的参数篡改技术获得对另一个用户帐户页的访问权限：
https://insecure-website.com/myaccount?id=456如果目标用户是应用程序管理员，则攻击者将获得对管理帐户页的访问权限。此页可能会泄漏管理员密码或提供更改密码的方法，或者可能提供对特权功能的直接访问。
2、涉及实验：
实验8：用户ID由密码泄露的请求参数控制
实验8：用户ID由密码泄露的请求参数控制
信息：
这个实验室有一个用户账户页面，其中包含当前用户的现有密码，预先填写了一个掩码输入
要解决这个实验室，检索管理员的密码，然后用它来删除 Carlos。
已有账号：wiener:peter
part1：
使用提供的凭据登录并访问用户帐户页面。
发现页面会包含自己密码，再次点击My account，分析数据包
发现通过参数名传参的参数
part2：
发送到repeater
将 URL 中的“ id”参数更改为管理员，并找到管理员密码
part3：
登陆管理员账户，删除 Carlos
iq8szu44yky140pdvu4b
7、不安全的直接对象引用
1、不安全直接对象引用（IDOR）是访问控制漏洞的一个子类。当应用程序使用用户提供的输入直接访问对象，并且攻击者可以修改输入以获得未经授权的访问时，就会出现IDOR。它因出现在OWASP 2007 Top Ten中而流行，尽管它只是许多可能导致绕过访问控制的实现错误中的一个例子
2、涉及实验：
实验9：不安全的直接对象引用
实验9：不安全的直接对象引用
信息：
这个实验室将用户聊天记录直接存储在服务器的文件系统中，并使用静态 URL 检索它们。
找到用户 Carlos 的密码，登陆他们的账户，解决实验室
part1：
选择 Live chat 选项卡。发送一条消息，然后选择 View transcript。
再次点击
分析HTTP历史记录
检查 URL 并观察到文本是分配给文件名的文本文件，其中包含一个递增的数字。
part2:
将文件名更改为1.txt 并查看文本
注意聊天记录中的密码。
part3:
返回到主实验室页面，并使用被盗凭证登录。
carlos
jsj56afvshbm5ozfl4qg
8、多步骤流程中的访问控制漏洞
1、许多网站通过一系列步骤实现重要功能。当需要捕获各种输入或选项时，或者当用户需要在执行操作之前查看和确认细节时，通常会执行此操作。
如更新用户详细信息的管理功能可能涉及以下步骤：
1、加载包含特定用户详细信息的表单。
2、提交更改
3、查看更改并确认。2、有时网站会对其中一些步骤实施严格的访问控制，但忽略其他步骤。如假设访问控制已正确应用于第一步和第二步，但未应用于第三步。实际上，网站假设用户只有在他们已经完成了被适当控制的第一步骤的情况下才将到达步骤3。在这里，攻击者可以跳过前两个步骤，直接提交包含所需参数的第三个步骤的请求，从而获得对函数的未授权访问。
3、涉及实验：
实验10：多步骤流程，其中一个步骤没有访问控制
实验10：多步骤流程，其中一个步骤没有访问控制
信息：
这个实验室有一个管理面板，它有一个有缺陷的改变用户角色的多步骤过程（可以通过使用凭据administrator: admin 登录来熟悉管理面板）
要解决实验室问题，使用凭据 wiener: peter 登录，并利用存在缺陷的访问控制来提升自己成为管理员
part：
使用管理凭据登录
浏览到管理面板，提升carlos，并将确认 HTTP 请求发送到bp的repeater
流程一：
流程二：
part2:
打开一个私有/匿名浏览器窗口，并使用非管理员凭证登录。
获取非管理员cookie
part3:
将非管理员用户的会话 cookie 复制到现有的转发请求中，将用户名更改为已有的用户名，然后重放
流程一：（会有鉴权）
提示未经授权
流程二：（提权成功）
302跳转和原始数据一致
9、基于引用的访问控制
1、原理：某些网站基于访问控制Referer HTTP请求中提交的标头。该Referer浏览器通常会在请求中添加一个标头，以指示发起请求的页面。
2、示例：如假设某个应用程序在主管理页上强制实施访问控制/admin，但对于子页面，如/admin/deleteUser用户只检查了Referer标题。如果Referer标头包含主/admin URL，则允许该请求。
3、利用：在这种情况下，由于Referer头可以完全由攻击者控制，他们可以伪造对敏感子页的直接请求，提供所需的Referer头，从而获得未经授权的访问
4、涉及实验：
实验11：基于引用的访问控制
实验11：基于引用的访问控制
信息：
这个实验根据 Referer 头控制对某些管理功能的访问（可以通过使用凭据administrator: admin 登录来熟悉管理面板）
要解决实验室问题，使用凭据 wiener: peter 登录，并利用存在缺陷的访问控制来提升自己成为管理员
part1:
使用管理凭据登录
浏览到管理面板，提升 Carlos
然后将 HTTP 请求发送到BP的repeater
part2:
打开一个私有/匿名浏览器窗口，并使用非管理员凭证登录
wiener: peter
在/admin-role?Username = carlos & action = update请求中，如果缺少 Referer 头，请求被视为未授权
将非管理员用户的会话 cookie 复制到现有的 Burp Repeater 请求中，将用户名更改为已有的，然后重放
和原有数据一样进行了跳转
10、基于位置的访问控制
1、一些网站基于用户的地理位置对资源实施访问控制。如这可以应用于州立法或业务限制适用的银行应用或媒体服务。这些访问控制通常可以通过使用Web代理、VPN或操纵客户端地理定位机制来规避。
★
欢 迎 加 入 星 球 ！
代码审计+免杀+渗透学习资源+各种资料文档+各种工具+付费会员
进成员内部群
星球的最近主题和星球内部工具一些展示
关 注 有 礼
还在等什么？赶紧点击下方名片关注学习吧！
推荐阅读
如有侵权请联系:admin#unsafe.sh