BOOK THIS SPACE FOR AD
ARTICLE ADImagine a library where everyone has their own locker to store their favorite books. Each locker has a number and a key. Only the person with the correct key should access their locker.
Now, the librarian decides to use an electronic system where you enter your locker number into a computer to open it. But, the system isn’t smart enough to check if the person entering the number is actually the locker owner. So, if your locker number is 123, you would enter "123" on the computer to open it.An inquisitive kid discovers this and decides to try different locker numbers. When they enter "124," they can open someone else’s locker and see their books.
This is how IDOR works in the digital world:
by changing the locker number in the URL or form data, someone can access or manipulate data they shouldn’t have access to. Proper checks (like ensuring the person has the right key) prevent this kind of unauthorized access.
In the story, the locker numbers are like user IDs in a URL. For instance, imagine a web application where users can view their profile by visiting a URL like
http://example.com/profile?user=123Here, 123 is the locker number.Just like the inquisitive kid, an attacker might try changing the user parameter to another number, like
http://example.com/profile?user=124If the web application doesn’t check if the user is authorized to view profile 124, the attacker can access someone else’s profile.In a secure system, just as the librarian should ensure only the correct person can open their locker, the web application should verify that the user has permission to access the data associated with the ID they are trying to access. Without this check, the system is vulnerable to IDOR attacks.
Ping on 𝕏 : 1hehaq
haq