Fuzzing + IDOR = Admin TakeOver

Hello everyone, this is my first post. I’ve been thinking about writing about my findings for a while, so here we go.


Please let me know if you notice any spelling errors.



We will call the victim web “example.com”. This objective has 6 well defined user roles. The user with low privileges I call it “Low Privilege” and the one with higher privileges I call it “Super Admin”.


Step 01


I love the fuzz, so first of all I started with fuzzing against the endpoint “/api/FUZZ” without login in the app, using the tool ffuf:

我喜欢模糊,所以首先我使用 ffuf 工具,在不登录的情况下对端点“/api/FUZZ”进行模糊化:

I found 4 endpoints, 2 of them are important here:


  • user/users 用户/用户
  • user/updateuser 用户/更新用户

Step 02


I make a request against the found endpoint and I can see that the server only accepts the POST method:

我对找到的端点发出请求,我可以看到服务器只接受 POST 方法:

Step 03


I change the method to POST:

我将方法改为 POST:

And I can see that a message is displayed for lack of authorization to interact with the resource (endpoint):


Step 04


At this point, I need an authorization token. To obtain it, I log in to the application with my “Low Privilege” user account:

此时,我需要一个授权令牌。为了获得它,我用我的“ Low Privilege”用户帐户登录到这个应用程序:

I click on any request and intercept the valid request on the backend, which attaches the “Authorization” header with the JWT:

我点击任何请求并拦截后端上的有效请求,后端将“ Authorization”头附加到 JWT:

Step 05


From the endpoint “/api/vehicle/getLoggedInUserBookings” I can see a header “Authorization: Bearer [token]”:

在端点“/api/vehicle/getloggetdinuserbookings”中,我可以看到一个头文件“ Authorization: Bearer [ token ]”:

Step 06


I copy and paste this header in my request from Step 03. I add the “Authorization” header with the token that I captured previously and make the request. At this point I noticed a new error message returned by the application:

我复制并粘贴这个头在我的要求从步骤03。我添加了“ Authorization”头和我之前捕获的令牌,然后发出请求。这时我注意到应用程序返回了一个新的错误消息:

Step 07


Now, the first thing I think about is “balancing” the request to get a clean response from the server. This got me thinking about changing some headers like “Content Type” and “Accept”. Also, I always add a random parameter (JSON format) in the request with a random value to determine how the server reacts:

现在,我考虑的第一件事是“平衡”从服务器获得干净响应的请求。这让我考虑修改一些头文件,比如“ Content Type”和“ Accept”。此外,我总是在请求中添加一个带有随机值的随机参数(JSON 格式) ,以确定服务器的反应:

Step 08


My first thought when faced with a new API is to save every single parameter I come across along the way. Continuing with this thought, I use the parameters I found in the request from Step 05 to debug the responses and try to get an accurate HTTP 200 OK response:

当面对一个新的 API 时,我的第一个想法是保存一路上遇到的每一个参数。继续这个想法,我使用我在步骤05的请求中找到的参数来调试响应,并试图得到一个准确的 HTTP 200 OK 响应:

The message “User details fetch successfully” tells me that everything is fine!

“ User details fetch successfully”消息告诉我一切正常!

Step 09


It is an important point in the exploitation, since I must look for one or more parameters that allow me to obtain more information.


Okay, using fuzzing techniques again, I find a valid parameter. This parameter was found with the name of ‘“role: 1”’:

好的,再次使用 fuzzing 技术,我找到了一个有效的参数:

The correct syntax to get the correct result with ffuf is as follows:

使用 ffuf 获得正确结果的正确语法如下:

ffuf -w g0ld3n-api.txt -u https://vulnerable.com/api/endpoint -X POST --data '{"param1":value1,"param2":value2,"FUZZ":6}' -H 'Authorization: Bearer JWT'

Step 10


Then I send the request with this new parameter (role) and the server returns me confidential information about all the users with the “role” equal to “6” corresponding to the Low Privilege role:

然后,我用这个新参数(角色)发送请求,服务器会返回所有“ role”等于“6”的用户的机密信息,这些“ role”对应于 Low Privilege 角色:

Step 11


At this point I can detect that the API is vulnerable to IDOR in its functionality to view user information. Now, will it also be true for the “update user” endpoint found previously in Step 01?

此时,我可以检测到,该 API 在其查看用户信息的功能方面容易受到 IDOR 的攻击。现在,对于之前在步骤01中发现的“更新用户”端点也是这样吗?

I use the parameters found in Step 10 and start debugging to find a valid response from the server against the endpoint “/user/updateuser”. Once I achieve the “balance” to make the correct request, I change the value of the parameter ‘”role “: 6’ to ‘“role”: 1’:

我使用步骤10中找到的参数并开始调试,以从服务器上针对端点“/user/updateuser”找到有效的响应。一旦我实现了“ balance”以提出正确的请求,我将参数“”role“ : 6”的值更改为“ role: 1”:

  • Role 6 = Low Privilege 角色6 = 低特权
  • Role 1 = Super Admin 1 = 超级管理员

I log in again with my user and I see that I am now Super Admin:


Thank you very much for reading and please let me know if you notice any errors or inconsistencies.


I leave my git and twitter in case you want to take a look at it:

我留下了 git 和 twitter,如果你想看看的话:

Take care!