As you know, nowadays web applications could be as complex as operating systems. Most of those complexity comes from authorisation schemas. Such weaknesses are referred to in the literature as Insecure Direct Object Reference.
Insecure Direct Object References occur when an application provides direct access to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly, for example database records or files.[1]
There are two different approach to solve IDOR. Since this article is intended to detect similar weaknesses in security audits, we will not perform a detailed analysis of these two methods.
Approach #1 – Using Indirect Object Reference
This prevents attackers from directly targeting unauthorized resources. For example, instead of using the resource’s database key, a drop down list of six resources authorized for the current user could use the numbers 1 to 6 to indicate which value the user selected. The application has to map the per-user indirect reference back to the actual database key on the server.[2]
Approach #2 – Access check
You have to think about following two question no matter how much controller or model you have.
- Which user are requesting this source ?
- Does that user have the authority to take this action ?
It turns out that there can be many authorization failures if different developers or even teams involved in the software development process. So the question is how we are going to detect this issues ?
Automated Scanners
Automated tools are cool but they are not capable to detect every single kind of vulnerabilities. When the topic comes to the business logic assessments, it would be hardest exam for scanners. Business logic assessment is a much more difficult process for automated tools than you might have guessed.
For example; We must supply different type of accounts into the automated web application security scanners in order to be able to detect authorisation issues. And then scanners need to login with an account, crawl every single URL and collect forms. In this way, scanners will be able to submit forms or fetch page with low privileges account’s session.
Manuel Tests Involves
Every single web application assessments must starts with questionnaire. One of the most important questions you are asking should be as follow.
How many different type of user privileges do you have in your application ? Please share it as authority matrix.
And answer should be shared with table as follow.
| User | Delete Post | Read Post | Update Post | Create Post |
| Admin | YES | YES | YES | YES |
| Moderator | NO | YES | YES | YES |
| Registered User | NO | YES | NO | NO |
As you can see there is a 3 different type of user alongside with 4 different action. This means our test cases must cover followings.
- Can moderator delete post ?
- Can registered user take an action except reading post ?
At first glance, those test cases might be looks easy. But actually they are not. Imagine that you are about the start penetration test against a web application that have 20+ different user role ?. Image that every single HTTP request must be repeated 20 times with 20 different valid session. Under this circumstances, your test cases will be increased enormously high. Beside that, repeating exactly same request with changed cookie and/or csrf token would be another disincentive point. It’s obvious we need a semi-automated tool.
Thanks God, We have Burp Suite
It would be unnecessary to say how awesome tool Burp is. One thing that I love most about Burp is a extender feature. You can process all incoming and outgoing HTTP request and take a specific action you want!
There is a one extender plug-in called as AuthMatrix developed by Security Innovation’s engineers. I’ve met with AuthMatrix plug-in before it placed on BApp Store and now it’s almost been a 3 year experience for me.
Let’s have a look at AuthMatrix and how it helps us to automate testing for authorisation issues.
AuthMatrix
AuthMatrix is an extension to Burp Suite that provides a simple way to test authorization in web applications and web services. With AuthMatrix, testers focus on thoroughly defining tables of users, roles, and requests for their specific target application upfront. These tables are displayed through the UI in a similar format to that of an access control matrix common in various threat modeling methodologies.
Once the tables have been assembled, testers can use the simple click-to-run interface to kick off all combinations of roles and requests. The results can be confirmed with an easy to read, color-coded interface indicating any authorization vulnerabilities detected in the system. Additionally, the extension provides the ability to save and load target configurations for simple regression testing.[3]
Usage of this plug-in is extremely easy.
- Create roles for all privilege levels within the target application. (Common roles may include User, Admin, and Anonymous)
- Create enough users to fit these various roles and select the checkboxes for all roles that the user belongs to.
- From another area of Burp Suite (i.e. Target tab, Repeater Tab, etc) right click a request and select “Send to AuthMatrix.”
- In the second table of AuthMatrix, select the checkboxes for all roles that are authorized to make each HTTP request.
- Create a Response Regex based on the expected response behavior of the request to determine if the action has succeeded.
- Common regexes include HTTP Response headers, success messages within the body, or other variations within the body of the page.
- NOTE: Messages can be configured to use a Failure Regex instead through the right-click menu (i.e. Anonymous should never receive an HTTP 200)
- Generate session tokens for each user from the Repeater tab and enter them into the relevant column within the first table (Cookies, HTTP Header, HTTP Parameter).
- If the target uses static CSRF tokens, place these into the HTTP Parameter column
- NOTE: Multiple cookies can be added using a “;” separator. Currently, only one HTTP Header or HTTP Parameter is supported.
- Click Run at the bottom to run all requests or right click several messages and select run. Observe that the adjacent table will show color-coded results.
- Green indicates no vulnerability detected
- Red indicates the request may contain a vulnerability
- Blue indicates that the result may be a false positive. (This generally means there is an invalid/expired session token or an incorrect regex)
Tips & Tricks
As someone who has worked for many years on application security auditing, I strongly recommend you to pay attention to the following items when using this add-on.
- Testing authorization issues with AuthMatrix on read operation is totally okay. But we also need to test delete, create and update operations. Especially using AuthMatrix on delete operation probably will fail due to deletion of requested source in first test case.
- I’ve seen several application that returns HTTP 200 OK along side with “Successfully …” message. Perform detailed analysis before jumping into the business assessment test. I usually choose to use AuthMatrix after second days of assessment. In this way, I be aware of every single success/error message.
References:
[1] – https://www.owasp.org/index.php/Testing_for_Insecure_Direct_Object_References_(OTG-AUTHZ-004)
[2] – https://www.owasp.org/index.php/Top_10_2010-A4-Insecure_Direct_Object_References
[3] – https://github.com/SecurityInnovation/AuthMatrix
