Direct Access and Completely Unprotected Functionality

In many cases of broken access controls, sensitive functionality and resources can be accessed by anyone who knows the relevant URL.  Some applications may enforce access controls by simply not displaying the usable link or button to access the resource.

To effectively scan for these weaknesses, first open an intercepting proxy and login with an administrative account.  Start navigating to administrative pages, focusing on features the generate reports, provide downloads, open PDF files, and other similar resources while marking each request in the proxy.  Log off, clear the cookies/cache, and login with the lower privileged account.  Start clicking on links from the proxy to see if any of these pages can be reached by the lower level account.

Client-Side Code

In some applications where sensitive functionality is hidden behind URLs that are not easy to guess, an attacker may often be able to identify these weaknesses by inspecting the view source or HTML response.

To effective scan for this type of weakness, again login with an administrative account and open an intercepting proxy and start navigating through both administrative and non-administrative pages.  After that, login with a non-administrator account and search for pages with read-only fields.  In the HTML responses, search for terms such as “admin”, “readonly”, or disabled.  If an admin variable is found, try changing it to true in the response, or is a field is set to “readonly”, try removing the tag.

Identifier-Based Functions

Applications using parameters in the URL to gain access to certain resources may be vulnerable to horizontal privilege escalation.  An example would be “https://somesite.com/viewdocument.php?docid=10293821”.  Any user who requests a relevant URL may be able to view a document they are unauthorized to view.  Another similar example would be a URL similar to “https://somesite/[userid]/viewprofile”.

Parameter-Based Access Controls

In some applications, a user’s role or access level at the time of login and from this point onward is transmitted via the client in a hidden form field, cookie, or preset query string parameter.  This type of access control may sometimes be difficult to detect without actually using the application as a high-privileged user, but it’s necessary to identify what requests are made and what the differences are in the requests.

Referrer-Based Access Control

Another unsafe access control model uses the applications HTTP referrer header as a basis for making access control decisions.  For example, an application may strictly control access to the main administrative menu based on a user’s privileges, but when a user makes a request for an individual admin function, the application may simply check whether this request was referred from the administrative menu page.

Forging Requests

Another method of escalating a user’s privileges is by capturing a request from an administrative feature.  Although access to these features may be restricted, using a forged request may be allowable.  Features such as user emulation may give low level users the ability to act as a super user.

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About Jean Fleury

Naval officer, privateer, cyber security professional. Traded in my five-ship squadron for a computer and Burp Suite license.

Category

Web Application Penetration Testing

Tags

, , , , , ,