This post intends to serve as a guide for some easy wins to look for when pentesting a web application for weak authorization controls. Note that this differs from Broken Authentication Controls, as Authentication takes place before Authorization comes in.

This post will be updated as I learn more about broken controls to look for.

---

Incrementing numbers in URL

• The application may be built to separate user accounts based on a decimal value. For example, your session may be tied to a specific ID value of 3. What were to happen if you modified this value to show you the information for a value of 4? Or 5? 6? You could use Burpsuite Intruder to help automate incrementing these values to get an idea of what values may return results.

_{^{Example: The page that you’re authorized to see may be http://example.com/info/3. Can you access sensitive information by going to http://example.com/info/4 instead?}}

• In some cases, checks may be in place that prevent you from accessing certain pages using this method, but you should check to make sure other features also include these checks.

^{Example: You’re authorized to see the following URLs as part of your logged in session: http://example.com/info/3 and http://example.com/info/3/edit. If you try to access another user’s info page, it will sign you out. However, the checks were not implemented properly when you try to access their edit page at http://example.com/info/4/edit}

---

Viewing data in other formats

• The HTML result on the page may be presented to you in a “hidden” format. However, you may be able to query the webserver to present the raw data to you in a different format, such as JSON. In some cases, the server could be configured to obfuscate the data when displayed as HTML, but may not be configured with the same obfuscation when viewing the data in other formats.

^{Example: The domain is http://example.com/1. You may be able to view the page in other formats by going to the file directly in the browser, or by querying it with Curl.}

• ^{Access the page in the Browser:
  http://example.com/1.js or http://example.com/1.json}
  
• ^{Access the page via Curl:
  curl http://example.com/1 -H 'Accept: application/json'}

---

Checking for Mass Assignment Vulnerabilities

• Some webapps will send post requests with attributes in them. Even if you don’t see the attribute in the request, you may be able to guess the name of an attribute and set a value to it. If you guess correctly, and the request is interpreted on the server, you may be able to do things that were not intended.

Example: Imagine we’re registering a user account. When registering the account, the post request to the server may look like the following.
user[username]=user1&user[password]=password1&submit=Submit Query

We can intercept our request and add an additional attribute that will assign admin rights to our user.
user[username]=user1&user[password]=password1&user[admin]=True&submit=Submit Query

But don’t just stop there! If admin=true doesn’t work, you can try a handful of other items.

Example: The server may be expecting a different value, such as:
admin=1
admin=yes
isadmin=1
isadmin=true

• You can also test for other attributes, not just ones that will make you an admin. However, you may have to guess them if they are not visible to you.

Example: The registration page also discusses multiple organizations that you can be a part of. Your original post request may look the following:
user[username]=user1&user[password]=pass&submit=Submit Query

But we could modify it so that it looks like this instead.
user[username]=user1&user[password]=pass&submit=Submit Query&user[organisation_id]=1