webgoat-Broken Access ControlI 访问控制失效
Insecure Direct Object References不安全的直接对象引用
直接对象引用
直接对象引用是指应用程序使用客户端提供的输入来访问数据和对象。
例子
使用 GET 方法的直接对象引用示例可能如下所示
https://some.company.tld/dor?id=12345
https://some.company.tld/images?img=12345
https://some.company.tld/dor/12345
其他方法
POST、PUT、DELETE 或其他方法也可能容易受到影响
不安全的直接对象引用
当引用未得到正确处理时，是不安全的，可能被权限绕过，或者泄露私人数据，或者用户也可以执行本无法执行的操作，访问不该访问的数据。
假设作为用户，查看个人资料，URL 如下所示：
https://some.company.tld/app/user/23398
这里的url中暴露的是用户id，如果修改id，是否能查到其他用户信息？
https://some.company.tld/app/user/23399…或在末尾使用另一个数字。如果您可以操作数字（用户 ID）并查看他人的配置文件，则对象引用是不安全的。 当然，这可以检查或扩展到 GET 方法之外，查看数据或者操作数据。
更多好读物
https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_（OTG-AUTHZ-004）
https://www.owasp.org/index.php/Top_10-2017_A5-Broken_Access_Control
https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheet.html
https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References
http://cwe.mitre.org/data/definitions/639.html
先进行身份验证，后滥用授权
许多访问控制问题容易受到经过身份验证但未经授权的用户的攻击
0x02
直接使用tom cat登录
观察差异和行为
从进攻端来看，AppSec 的一个一致原则是查看原始响应与可见响应的差异。 换句话说（正如您可能已经在客户端筛选课程中注意到的那样），原始响应中通常有数据不会显示在屏幕/页面上。 查看下面的配置文件并注意差异。
0x03
点击profile，查看响应，repsonse中有几个属性，页面上没显示的属性是role和userid
猜测模式
我们正在测的应用似乎遵从restful风格，很多app都有可以让用户访问其他用户信息的角色，所以/profile不能告诉我们，我们要访问的是哪个用户的信息。所以请猜测有没有方式可以使用直接对象引用来查看你的信息？
0x04
因为上一节接口给出了隐藏字段role，userid，所以猜测用userid可以访问。
填写为WebGoat/IDOR/profile/2342384 提交
意思是直接使用userid就可以查询该id的信息。如果知道了其他用户的id，那就也可以查询信息了。
在restful风格中，提供使用同样的url，不同的方法来进行处理，可以利用这样的模式，比如修改方法，传body，看能否对某些属性做出修改。
0x05
参考A1-Insecure Direct Object References - 知乎 (zhihu.com)
本题的主题是Insecure Direct Object References，不安全的对象引用，本质上是后端的验证逻辑有问题，直接相信了前端传进来的参数来进行逻辑处理，而导致的越权访问。
在实际的场景下，研发人员通过请求的id参数获取到参数的值以后，一般会根据该id去查询数据里面的数据。在查询之前有一个很重要的验证：
使用后端session中获取到该用户的信息，然后根据该用户绑定的数据范围去查询属于该用户的数据。
也就是不能用前端传进来的用户id作为识别用户的条件，因为前端参数是可以被篡改的
安全的对象引用
1、要有权限控制文档。权限控制是由业务逻辑定义的。
2、水平和垂直权限控制，通常我们使用角色来进行权限控制，但是同样角色的用户，也可能获取到其他用户的信息，这就是水平权限，也需要进行控制。
3、审计。权限控制规则应该包括哪些操作应该被记录下来，如超级用户或者管理员修改了其他人的信息，应该有日志记录。另外试图破坏权限控制机制的操作也应该记录下来。
4、使用间接引用。这个的方法用的比较少，可以hash，编码或者其他的方法，使客户端看到的id不是真实的引用对象，
这会降低一些处理效率，但是也容易被猜测，暴力破解，或者反编译。
5、权限控制API 如 JSON Web Tokens (https://jwt.io和Secure Token Binding
Missing Function Level Access Control缺少功能级别访问控制
在整个应用，方法/功能都需要做权限控制。
IDOR 与缺少功能级访问控制
很多人会将功能级访问控制和 IDOR （即不安全的直接对象引用）组合成“Access control”。但是这两者是有区别的。
最明显的区别是 IDOR 更多的是“水平”或“横向”访问控制问题，而缺少功能级别访问控制会“expose functionality”。尽管此处的 IDOR 课程演示了如何公开功能（至少向具有相同角色的其他用户），但我们将研究可能公开功能的其他方式。
Relying on obscurity
可以使用 HTML, CSS, or javascript 隐藏用户一般用不到的链接. 在过去，一个网络路由视图使用js在UI中隐藏管理员相关功能。Blogger: Time Warner Routers Still Hackable Despite Company Assurance | WIRED.
找到隐藏内容
There are usually hints to finding functionality the UI does not openly expose in:
-
HTML or javascript comments
-
Commented out elements
-
Items hidden via CSS controls/classes
作业0x02
在下面的菜单中找到攻击者/恶意用户感兴趣的两个不可见菜单项，并提交这些菜单项的标签（菜单中目前没有链接）
查看html页面，可以看到还有一个被隐藏的菜单，下面有三个li标签，每个标签有一个href。
这些href如果没有做权限控制，就可能被攻击者利用。
收集用户信息
利用权限控制漏洞，可以获取用户信息。
Often data dumps originate from vulnerabilities such as SQL injection, but they can also come from poor or lacking access control.
It will likely take multiple steps and multiple attempts to get this one:
-
Pay attention to the comments and leaked info.
-
You’ll need to do some guessing too.
-
You may need to use another browser/account along the way.
作业0x03
本题要求根据收集到的隐藏信息，找到user列表，并找到某个用户的hash值。
根据上一题的信息收集，我们得知了/users与/config链接，但是我直接访问localhost/WebGoat/users没有任何可用的信息，一开始以为是题目问题，知道看别人的解法，请求/users时把content-type改为application/json 得到hash值。
作业0x04
要求对第二题找到的链接/WebGoat/access-control/users-admin-fix，根据这个链接，获取jerry的hash。
参考：A1-Missing Function Level Access Control - 知乎 (zhihu.com)
1、 GET方法访问这个链接，提示403，权限不够，只有admin可以访问
2、在源码里，针对这个链接还有一个post方法，可以用来设置用户的角色。
用post方法请求，将当前自己的账号设置为admin
3、然后GET方法请求
这个题的bug之处在于如果没有源码，不知道可以设置角色，那就解不出来了。
总结：对于url，method,function都要做access control，不要试图通过hide信息让用户无法访问，一旦这些信息泄露，被攻击者发现，就over了。