Using Burp to Test for Missing Function Level Access Control

Anyone with network access to an application can send a request to it. Therefore, web applications should verify function level access rights for all requested actions by any user. If checks are not performed and enforced, malicious users may be able to penetrate critical areas of a web application without proper authorization.

In this example we will demonstrate two typical access control attacks on a training web application (WebGoat).

The version of WebGoat we are using is taken from OWASP’s Broken Web Application Project. Find out how to download, install and use this project.

Parameter Manipulation

OWASP_AccessControls_1

First, ensure that Burp is correctly configured with your browser.

With intercept turned off in the Proxy "Intercept" tab, visit the web application you are testing in your browser.

 
OWASP_AccessControls_2

The web application on this WebGoat page (Access Control Flaws - Stage 1: Bypass Business Layer Access Control Scheme) allows an employee to view their staff profile.

First, log in to one of the employee profiles.

In this example we are using "Larry".

 
OWASP_DataExposure_3

Return to Burp.

In the Proxy "Intercept" tab, ensure "Intercept is on".

 
OWASP_AccessControls_4

In your browser click the "View Profile" button.

Burp will capture the request, which can then be edited before being forwarded to the server.

 

 
OWASP_AccessControls_5

One way to easily locate and edit parameters is in the "Params" tab.

In this example we are changing the "employee_id" from "101" to "102".

Once the request has been edited, use the "Forward" button to forward the request.

In this example you will need to click the forward button more than once to get the appropriate response from the server and view the results in the web application.

 
OWASP_AccessControls_6

In the example, the application allows a user to access another user's employee profile page.

By editing the parameters in the request, the application's access controls have been bypassed.

 
 

Forced Browsing

OWASP_AccessControls_1

In this scenario the attacker uses forced browsing to access target URLs.

First, ensure that Burp is correctly configured with your browser.

Ensure Proxy "Intercept is off".

 

 
OWASP_AccessControlFB_1

In your browser, visit the page of the web application you are testing.

 
OWASP_DataExposure_3

Return to Burp.

In the Proxy "Intercept" tab, ensure "Intercept is on".

In your browser, resubmit the request to visit the page you are testing.

 
OWASP_AccessControlFB_2

You can now view the intercepted request in the Proxy "Intercept" tab.

Right click anywhere on the request to bring up the context menu.

Click "Send to Intruder".

 

 
OWASP_AccessControlFB_3

Go to the "Positions" tab under the "Intruder" tab.

Click the "Clear" button to clear the suggested payload positions.

 

 
OWASP_AccessControlFB_4

In this attack we are attempting to locate and view files and directories.

Select the file name in the URL and use the "Add" button to position the payload.

 

 
OWASP_AccessControlFB_5

Go to the "Payloads" tab.

"Payload type" in the "Payload sets" options should be set to "Simple list".

In the "Payload Options [Simple list]" from the dropdown menu "Add from list...", select "Directories - short" and "Filenames - short".

 
OWASP_AccessControlFB_6

Click the "Start Attack" button.

 

 
OWASP_AccessControlFB_7

An "Intruder Attack" window will pop up with the results of the attack.

You can sort the results using the column headers.

In this example we will use "Length". Click the "Length" column header.

"Status" would also be a useful method of organizing this results table.

 
OWASP_AccessControlFB_8

By sorting by "Length" or by "Status" we have enumerated some interesting results.

Send any results that warrant further investigation to Burp Repeater.

Right click on each individual result to bring up the context menu.

Click "Send to Repeater"

 
OWASP_AccessControlFB_9

Go to the "Repeater" tab.

Click "Go" to follow the request.

 
OWASP_AccessControlFB_10

In this example you have to use the "Follow redirection" button to follow the applications redirect and view the response.

In some of the results, forwarding the redirect leads to a 404 response, indicting there is no issue with this vulnerability.

 
OWASP_AccessControlFB_11

The "/conf" payload provides a redirect to a "200 ok" response.

You can view the response beneath the "Response" header or right click anywhere within the response to bring up the context menu.

Click copy "Copy URL".

Paste the URL in to your browser to manually check the results.

 

 
OWASP_AccessControlFB_12

In this example we are able to access the application's configuration page.

The application allows an unauthenticated user to configure administrative privileges and passwords for other users.

If an unauthenticated user can access URLs that should require authentication or hold sensitive information this is a security vulnerability.