XML External Entities Attack
OWASP Top10 series
Welcome to another post that is part of the OWASP TOP10 series!
In this we are going to explain about what Broken Access Control is and how it works together with how IDOR works as well. Tune in! 🧞
Typically there is certain web pages that are for only restricited access or for high privileged users like administrators where they can manage other users. Problem arises when just a regular visitor is able to access these protected pages therefore it can be mentioned the access controls are broken.
Definitely there is alot more into that in regards to Broken Access Control, but here we are just highlighting the foundation into understanding this vulnerability.
If a regular visitor suddenly has the privilege to access restricted pages, this can lead to alot of problems, few are like:
For instance, lets take this scenario into perspective:
A website uses a SQL call that uses unverified data to access informations of accounts:
ResultSet results = pstmt.executeQuery( );
To test this vulnerability, a malicious user just need to alter the “AllureAccount” parameter on the browser URL to anything else. If the verification is broken, an attacker can simply access information of another user’s account.
Another scenario, where a regular user or a malicious attacker can just directly browse to URL target which requires Admin privileges to access them.
Based on this two scenarios, we can safely say if an unauthorised user can access either of these pages, it can be considered a flaw, if an user who isnt an administrator can access admin pages, this is also a flaw.
Simply put, broken access control allows users to bypass authorization sections just like trespassing at unrestricted places on earth, which allows them see confidential information.
What’s really cool is an exploitation method in a way user inputs are being handled by websites, which is called Insecure Object Reference or in short IDOR. IDOR is a type of access control vulnerability.
Let’s say for example, we log into our bank account via web page to make some payments, once we are done authenticating ourselves, the URL will redirect to something like
https://bank.com/bank?account_number-1337. This page might contain personal information regarding bank, which is typically a normal procedure on web flows.
If you look at the URL redirect, you can spot a potential compromising issue. if this control is actually broken, a malicious user can change the
account_number parameter to something else like 4563, that might provide access to someone elses bank information or details even!
You can learn more about this from PortSwigger Academy