Common Web Application Vulnerabilities – Authorization Bypass
As we continue to try and share knowledge we’ve gained in our time performing penetration testing, we’re going to focus on another common web application vulnerability I keep running into. Authorization bypass is number 5 on the OWASP Top 10, further demonstrating that this continues to be a common issue plaguing web applications. The biggest problem with the different flavors of authorization bypass issues, which we’ll discuss here, is that this vulnerability is often an architectural problem based on how an application is designed and the authentication/session controls implemented. So fixes can be time consuming and complicated. This makes it even more important to raise awareness about these issues so that not only can testers be on the lookout for it, but also so application developers can try and avoid creating applications with authorization bypass weaknesses.
What is an Authorization Bypass?
First, it’s helpful if we all get on the same page to understand what I’m talking about when I say “authorization bypass.” This is simply any place within an application that I can access something I shouldn’t be able to. Any situation where I can view or manipulate content in an unintended manner counts as an instance where I am bypassing my intended level of authorization. This includes lateral movement (accessing data of another account at the same privilege level) and vertical movement or privilege escalation (accessing content I shouldn’t have access to in my current role). So this is clearly a very generic description of a vulnerability, and as you might be able to guess at this point, there are many different ways that this can be exploited in practice. Let’s cover a few of the most common:
Insecure Direct Object Reference
This is my favorite because it sounds so daunting and complex, but in reality, most people in this world have probably tried this kind of exploit without even knowing it. You know how sometimes URLs have parameters at the end of them like “?accountId=1&admin=true”? Insecure Direct Object Reference (IDOR) is when you change the “1” to a “2” and are able to access someone else’s account. Now obviously there are many different ways to do this in practice, with GET requests, POST requests, cookies, hidden fields, etc. But you would be amazed at how often this still works in applications. It’s also important to note here that if the parameters are not integers or simple values, that doesn’t mean the application isn’t vulnerable. The easiest exploitation here is when you are able to automate this in Burp Suite’s Intruder (or any intercepting proxy) and run through all accountIDs to see which ones you can access. Even if that accountId was a GUID though (32 character random alphanumeric string), I could still plug someone else’s accountId in to gain access to their data. Relying on hard to guess parameters just turns this into security by obscurity, and isn’t really protecting the data as much as just hoping no one finds another valid identifier.
Force Browsing
Another cool sounding name for another uncool exploit. Force browsing aka direct URL access aka typing a page you can’t see in the user interface into your browser and hitting enter to see what happens. If you can “force” your browser to visit a particular page that you don’t have access to through the user interface, this is likely an authorization bypass. These other “hidden” pages can be found from inspecting source code sometimes, using directory brute forcing tools (e.g. dirsearch, dirb, dirbuster, gobuster…), or just guessing page names and getting lucky (like /admin or /account).
Direct API Interaction
Although somewhat encompassed by the two methods above, I thought it was prudent to call out APIs specifically here. With newer application architectures and the rise of everything using APIs to facilitate asynchronous content, I guess developers just assume none of their users have an intercepting proxy at their disposal. But when browsing an application, if you see API calls flowing in the background you should be testing those for authorization bypasses as well. Oftentimes, developers will assume that all API calls will only have acceptable data provided by the front-end, so directly modifying these requests could bypass client-side-only authorization checks. For example, an application I tested a couple months ago used an API call to update my account information. In this API call was a parameter call “access” that was set to the integer “10”, even though I did not have an input field or drop-down of any kind that correlated to access level in the user interface. By intercepting that request and changing access from “10” to “100” I became a super user of the application.
So although these were just simple descriptions and a few quick examples, you can see these different kinds of issues in the wild or test them out for yourself with purposefully vulnerable web applications, such as OWASP’s Juice Shop or bWAPP. Authorization bypasses are issues in business logic that web application scanners will never find, as they are unable to reliably determine what a user “should” or “should not” have access to in most cases. This further highlights the benefits of having full web application penetration testing performed on at least an annual basis, particularly for public facing web applications, as these issues can have significant impacts associated with them. Reach out if you have any questions or want to discuss these vulnerabilities further!
