Enumerate Infrastructure and Application Admin Interfaces (OTG-CONFIG-005)

From OWASP
Revision as of 00:08, 23 August 2008 by Mr fusion (Talk | contribs)

Jump to: navigation, search

OWASP Testing Guide v3 Table of Contents

This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.

OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here

Contents


This is a draft of a section of the new Testing Guide v3

Brief Summary


Administrator interfaces may be present in the application or on the application server to allow certain users to undertake privileged activities on the site. Tests should be undertaken to reveal if and how this privileged functionality can be accessed by an unauthorized or standard user.

Description of the Issue


An application may require an administrator interface to enable a privileged user to access functionality that may make changes to how the site functions. Such changes may include:

- user account provisioning
- Site design and layout
- data manipultion
- configuration changes

In many instances, such interfaces are usually implemented with little thought of how to separate them from the normal users of the site. Testing is aimed at discovering these administrator interfaces and accessing functionality intended for the privileged users.

Black Box testing and example

The following describes vectors that may be used to test for the presence of administrative interfaces. These techniques may also be used for testing for related issues including privilege escalation and are described elsewhere in this guide in greater detail:

  • Directory and file Enumeration - An administrative interface may be present but not visibly available to the tester. Attempting to guess the path of the administrative interface may be as simple as requesting:

/admin or /administrator etc..
A tester may have to also identify the filename of the administration page. Forcible browsing to the identified page may provide access to the interface.

  • Comments and links in Source - Many sites use common code that is loaded for all site users. By examining all source sent to the client, links to administrator functionality may be discovered and should be investigated.
  • Reviewing Server and Application Documentation - If the application server or application is deployed in its default configuration it may be possible

to access the administration interface using information described in configuration or help documentation. Default password lists should be consulted if an administrative interface is found and credentials are required.

  • Alternative Server Port - Administration interfaces may be seen on a different port on the host. For example Apache Tomcat Administration interface can often

be seen on port 8080.

  • Parameter Tampering - A GET or POST parameter or a cookie variable may be required to enable the administrator functionality. Clues to this

include the presence of hidden fields such as:

<input type="hidden" name="admin" value="no"> or: Cookie: session_cookie; useradmin=0

Once an administrative interface has been discovered, a combination of the above techniques may be used to attempt to bypass authentication. If this fails, the tester may wish to attempt a brute force attack. In such an instance the tester should be aware of the potential for administrative account lockout if such functionality is present.

Gray Box testing and example

Code should be examined to ensure clear separation of duties and enforcement of user authorization and administration function access. The server and application components should be verified to ensure hardening and validation that they are not configured as the default.

References

Whitepapers
...
Tools
...