一、访问控制
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由请求参数控制，重定向时发生数据泄漏
