IDOR-2

许多访问控制问题容易受到经过身份验证但未经授权的用户的攻击。因此，让我们从合法身份验证开始。然后，我们将寻找绕过或滥用授权的方法。

这里只是输入tom或者cat进行登录，进入下一题进行IDOR审查

IDOR-3

抓包看一看没有显示的属性

看一下源码：

我们发现他把不相关的信息一并返回了，实际用的信息只有其中三个，而关于判定答案部分：

以，为分隔，检测答案是否为userid和role

IDOR-4

在另一个接口查看自己的profile

根据描述：

就概要文件而言，我们正在使用的应用程序似乎遵循RESTful模式。许多应用程序都具有提升用户可以访问另一用户内容的角色。在这种情况下，just/profile将不起作用，因为自己用户的会话/身份验证数据不会告诉我们他们想要查看谁的配置文件。那么，您认为使用直接对象引用显式查看您自己的配置文件的可能模式是什么？

这样的话想起之前我们得到了自己的userid，这里应该是通过userid确定我们需要查看的概要文件，这样的模式在实际情况中也很常见

看一下源码：

他这里对userid其实没有添加更多的验证和防护，很大程度上我们可以通过爆破或者猜测或者其他方法得到别人的userid就可以得到别人的profile信息

IDOR-5

这里访问别人的profile，爆破一下，跟之前说的一样，这里主要做代码审计，就不爆破了：

这个板块的源码给我的感觉有一点刻意了，这里第二个if就该截断才对，可能是单纯为了让我们感受一下吧…

Missing Function Level Access Control

缺少功能级别访问控制

事实上，许多人（包括本课的作者）会将功能级别的访问控制和IDOR归入“访问控制”。为了OWASP，前10名和这些教训，我们将进行区分。大多数人的区别在于，IDOR更多的是一个“水平”或“横向”访问控制问题，而缺少功能级别的访问控制“暴露了功能”。尽管这里的IDOR课程演示了功能是如何公开的（至少对同一角色的另一个用户），但我们将研究功能公开的其他方式。

2

在这里找到两个隐藏的表单

个人感觉不是很好找这种表单，尤其是在页面元素很多的时候，这道题大概猜测在Accout板块或者Messages板块。其实也看得眼花。。

3

根据题目，我们可以利用上提找到的信息，也就是两个接口，访问一下/users：

返回500，有点夸张，看一下源码：

看来要设置Content-Type,这里的GET请求方法的视图函数返回了所有user

挺离谱的，好像意料之外又情理之中

看一下hint里的复杂思路：

If the request to view users, were a ‘service’ or ‘RESTful’ endpoint, what would be different about it?

You will want to add WEBGOAT_ADMIN for the user’s role. Yes, you’d have to guess/fuzz this in a real-world setting.

OK, here it is. First, create an admin user … Change the method to POST, change the content-type to “application/json”. And your payload should look something like: {“username”:”newUser2”,”password”:”newUser12”,”matchingPassword”:”newUser12”,”role”:”WEBGOAT_ADMIN”}

也就是用post新创建一个admin用户，但是需要post的数据又是需要猜测一下的，按照hint就是需要猜测或者fuzz一下。看看源码怎么回事：