Testing for privilege escalation

When a user logs in to an application, they usually only have access to the parts of the application that they need to perform their specific tasks. If access controls are incorrectly set, a user can gain access to functionality that should only be available to higher-privileged users.

If you have credentials for a high-privileged and a low-privileged account, you can test the effectiveness of an application's access controls by accessing the application using different accounts. You can use Burp to send ad-hoc requests to compare access or automate the steps for sending multiple requests as a different user.

You can follow along with the processes below using the lab Method based access control can be circumvented from our Web Security Academy.

Before you start

Get credentials for an admin / high-privileged account and a low-privileged user.

Testing a specific endpoint

To run a quick test on specific endpoints, you can use Burp Repeater:

1. Go to the Proxy > Intercept tab and click Open browser.
2. Visit the target site and log in as a high-privileged user. If you're following along using the lab, you can use the credentials administrator:admin.
3. Access the admin panel and log out.
4. In Burp's browser, go back to the account page and log in as a low-privileged user. If you're following along using the lab, you can use the credentials wiener:peter.
5. Go to Proxy > HTTP history.
6. Right-click the admin panel request sent by the high-privileged user and select Send to Repeater.

7. Find the low privileged user's most recent request. Select the request and copy the session cookie.

   
8. Go to Repeater. Paste the low-privileged user's cookie into the admin panel request, replacing the original session cookie.
9. Click Send. Review the response to identify if privilege escalation was possible. In this case, we get a 401 Unauthorized response.

Testing across the entire site

Testing for privilege escalation on a large number of endpoints can be time-consuming. Burp Suite can help you to automate this process across all the requests in the current site map:

1. Map the application as a high-privileged user. If you're following along using the lab, you can use the credential administrator:admin. Browse around the application to populate Target > Site map making sure you visit the admin panel.
2. Log out, then log back in as a low-privileged user to obtain their session cookie. If you're following along using the lab, you can use the credentials wiener:peter.

3. Go to the Proxy > HTTP history tab. Select the low-privileged user's most recent request and copy the session cookie to use later.

   

4. Create a session handling rule that adds the low-privileged user's session cookie to all requests sent from the Target tool:

   1. From the Settings dialog, go to Sessions > Session handling rules and click Add. The Session handling rule editor opens.
   2. Go to the Scope tab.
   3. Under Tools scope, select Target and deselect all other tools.
   4. Under URL scope, select Use custom scope, click Add, then enter the URL of the target site.
   5. Go to the Details tab to define the rule.
   6. Under Rule actions, click Add, then select Set a specific cookie or parameter value. The Session handling action editor opens.

   7. Set the following details to add the low-privileged user's session cookie.

      Name: session

      Value: The cookie you copied from your low-privileged user's request

   8. Keep clicking OK to close all open dialogs. The rule is added to the list of session handling rules.

5. Re-request the entire site map as a low-privileged user:

   1. Go to the Target > Site map tab, right-click the target host, then select Compare site maps. The Compare site maps dialog opens.
   2. Select Use current site map, then click Next.
   3. Select Use only selected branches.
   4. Select Request map 1 again in a different session context.
   5. Keep the default settings for each of the remaining steps.
   6. Review the two site maps. Any differences are highlighted. Pay close attention to the admin panel requests. Notice that the high-privileged user was able to access the admin panel, but the low-privileged user received a 401 Unauthorized, confirming that this endpoint is not vulnerable in this case.