4.0

57
Web Application Penetration Testing
may be tempted to zip them first. Be careful not to forget behind
those archive files.
• Appropriate configuration management policies should help not to
leave around obsolete and unreferenced files.
• Applications should be designed not to create (or rely on) files stored
under the web directory trees served by the web server. Data files,
log files, configuration files, etc. should be stored in directories
not accessible by the web server, to counter the possibility of
information disclosure (not to mention data modification if web
directory permissions allow writing).
• File system snapshots should not be accessible via the web if the
document root is on a file system using this technology. Configure
your web server to deny access to such directories, for example
under apache a location directive such this should be used:
Order deny,allow
Deny from all
Enumerate Infrastructure and Application Admin
Interfaces (OTG-CONFIG-005)
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.
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 manipulation
• configuration changes
In many instances, such interfaces do not have sufficient controls to
protect them from unauthorized access. Testing is aimed at discovering
these administrator interfaces and accessing functionality intended
for the privileged users.
How to Test
Black Box Testing
The following section describes vectors that may be used to test for
the presence of administrative interfaces. These techniques may also
be used to test for related issues including privilege escalation, and are
described elsewhere in this guide(for example Testing for bypassing
authorization schema (OTG-AUTHZ-002) and Testing for Insecure Direct
Object References (OTG-AUTHZ-004) 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.. or in some scenarios can
be revealed within seconds using Google dorks.
• There are many tools available to perform brute forcing of server
contents, see the tools section below for more information. * A
tester may have to also identify the file name of the administration
page. Forcibly browsing to the identified page may provide access to
the interface.
• Comments and links in source code. 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.
• Publicly available information. Many applications such as wordpress
have default administrative interfaces .
• Alternative server port. Administration interfaces may be seen on
a different port on the host than the main application. For example,
Apache Tomcat’s 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:
or in a cookie:
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
A more detailed examination of the server and application components
should be undertaken to ensure hardening (i.e. administrator
pages are not accessible to everyone through the use of IP filtering
or other controls), and where applicable, verification that all components
do not use default credentials or configurations.
Source code should be reviewed to ensure that the authorization and
authentication model ensures clear separation of duties between
normal users and site administrators. User interface functions shared
between normal and administrator users should be reviewed to ensure
clear separation between the drawing of such components and
information leakage from such shared functionality.
Tools
• Dirbuster This currently inactive OWASP project is still a great tool for
brute forcing directories and files on the server.
• THC-HYDRA is a tool that allows brute-forcing of many interfaces,
including form-based HTTP authentication.
• A brute forcer is much better when it uses a good dictionary, for