IDOR, or Insecure Direct Object Reference, is the act of exploiting a misconfiguration in the way user input is handled, to access resources you wouldn’t ordinarily be able to access.
For example, let’s say we’re logging into our bank account, and after correctly authenticating ourselves, we get taken to a URL like this
https://example.com/bank?account_number=1234. On that page we can see all our important bank details, and a user would do whatever they needed to do and move along their way thinking nothing is wrong.
There is however a potentially huge problem here, a hacker may be able to change the account_number parameter to something else like 1235, and if the site is incorrectly configured, then he would have access to someone else’s bank information.
After logging in with the credentials provided
By checking the URL we can see the
And in the previous task (task 3) you had read that
However, as you may have picked up on, there seems to be an interesting part of the URL. It seems that the note that we can view is controlled by a URL parameter, let’s check if we can access other notes, by increasing the number to 2.
IDOR can also have negative values as well like
The note parameter is set to 1, lets try changing it to 0.
(When dealing with numerical id’s, my preference is to start fuzzing from 0 ( As admin accounts are first to be created, so they usually have low index numbers such as 0 or 1) and increment to an arbitrary value (User accounts are made after the admin accounts so they have greater index value)., depending on how many users the application is likely to contain (such as 5,100,1242 etc..).
After changing the value to 0, we get a flag!
Forced browsing is the art of using logic to find resources on the website that you would not normally be able to access. For example let’s say we have a note taking site, that is structured like this.
http://example.com/user1/note.txt . It stands to reason that if we did
http://example.com/user2/note.txt. We may be able to access user2’s note.
Taking this a step further, if we ran wfuzz on that URL, we could enumerate users we don’t know about, as well as get their notes. This is quite devastating, because we can then run further attacks on the users we find, for example brute forcing each user we find, to see if they have weak passwords.
Q1:What flag hides characters
Q2. What flag shows specific word amounts instead of hides them
Browse to port 81
We can use any password combination. I used →
Let’s brute force the
noot field using
wfuzz -c -z file,common.txt http://IP:81/FUZZ/note.txt
The wordlist common.txt can be found in
As we can see, we are getting a lot of
404 responses which have
57 words. We can block it using the
--hw 57 or
--hc 404 .
wfuzz -c -hw 57 -z file,common.txt http://IP:81/FUZZ/note.txt
wfuzz -c -z file,common.txt -hc 404 http://IP:81/FUZZ/note.txt
Let’s browse to
http://ip:81/REDACTED/note.txt to get the flag.
This is a bit of a unique one, as it can basically be anything. APIs are by definition incredibly versatile, and finding out how to exploit them, will require a lot of research and effort by the hacker. The following situation is only one possible scenario out of a near infinite number.
TASK 10 — READ AND MARK THE NO ANSWER REQUIRED
Browse to port 82
Login with random username and password.
The hint says : The parameter you need to use may not be the same. If you’re looking for a wordlist, you can use big.txt.
big.txt can be found in
I tried bruteforcing it didnt get expected results. I thought to check out the usual file names where flags are stored like
/flag.txt was the location where the flag was stored.
Hope you enjoyed the walkthrough.