4.0
1NSchAb
1NSchAb
- No tags were found...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
47<br />
Web Application Penetration Testing<br />
framework-specific folders<br />
• Do not use default scripts on the page or obfuscate them if they<br />
must be used.<br />
Specific files and folders<br />
General guidelines:<br />
• Remove any unnecessary or unused files on the server. This implies<br />
text files disclosing information about versions and installation too.<br />
• Restrict access to other files in order to achieve 404-response when<br />
accessing them from outside. This can be done, for example, by modifying<br />
htaccess file and adding RewriteCond or RewriteRule there. An<br />
example of such restriction for two common WordPress folders is presented<br />
below.<br />
RewriteCond %{REQUEST_URI} /wp-login\.php$ [OR]<br />
RewriteCond %{REQUEST_URI} /wp-admin/$<br />
RewriteRule $ /http:/your_website [R=404,L]<br />
However, these are not the only ways to restrict access. In order to<br />
automate this process, certain framework-specific plugins exist. One<br />
example for WordPress is StealthLogin (http:/wordpress.org/plugins/<br />
stealth-login-page).<br />
Additional approaches<br />
General guidelines:<br />
[1] Checksum management<br />
The purpose of this approach is to beat checksum-based scanners<br />
and not let them disclose files by their hashes. Generally, there are two<br />
approaches in checksum management:<br />
• Change the location of where those files are placed (i.e. move them<br />
to another folder, or rename the existing folder)<br />
• Modify the contents - even slight modification results in a completely<br />
different hash sum, so adding a single byte in the end of the file<br />
should not be a big problem.<br />
[2] Controlled chaos<br />
A funny and effective method that involves adding bogus files and<br />
folders from other frameworks in order to fool scanners and confuse<br />
an attacker. But be careful not to overwrite existing files and folders<br />
and to break the current framework!<br />
Map Application Architecture (OTG-INFO-010)<br />
Summary<br />
The complexity of interconnected and heterogeneous web server infrastructure<br />
can include hundreds of web applications and makes configuration<br />
management and review a fundamental step in testing and<br />
deploying every single application. In fact it takes only a single vulnerability<br />
to undermine the security of the entire infrastructure, and even<br />
small and seemingly unimportant problems may evolve into severe<br />
risks for another application on the same server.<br />
To address these problems, it is of utmost importance to perform an<br />
in-depth review of configuration and known security issues. Before<br />
performing an in-depth review it is necessary to map the network and<br />
application architecture. The different elements that make up the infrastructure<br />
need to be determined to understand how they interact<br />
with a web application and how they affect security.<br />
How to Test<br />
Map the application architecture<br />
The application architecture needs to be mapped through some test<br />
to determine what different components are used to build the web<br />
application. In small setups, such as a simple CGI-based application, a<br />
single server might be used that runs the web server which executes<br />
the C, Perl, or Shell CGIs application, and perhaps also the authentication<br />
mechanism.<br />
On more complex setups, such as an online bank system, multiple<br />
servers might be involved. These may include a reverse proxy, a frontend<br />
web server, an application server and a database server or LDAP<br />
server. Each of these servers will be used for different purposes and<br />
might be even be divided in different networks with firewalls between<br />
them. This creates different DMZs so that access to the web server<br />
will not grant a remote user access to the authentication mechanism<br />
itself, and so that compromises of the different elements of the architecture<br />
can be isolated so that they will not compromise the whole<br />
architecture.<br />
Getting knowledge of the application architecture can be easy if this<br />
information is provided to the testing team by the application developers<br />
in document form or through interviews, but can also prove to<br />
be very difficult if doing a blind penetration test.<br />
In the latter case, a tester will first start with the assumption that<br />
there is a simple setup (a single server). Then they will retrieve information<br />
from other tests and derive the different elements, question<br />
this assumption and extend the architecture map. The tester will start<br />
by asking simple questions such as: “Is there a firewalling system protecting<br />
the web server?”. This question will be answered based on the<br />
results of network scans targeted at the web server and the analysis<br />
of whether the network ports of the web server are being filtered<br />
in the network edge (no answer or ICMP unreachables are received)<br />
or if the server is directly connected to the Internet (i.e. returns RST<br />
packets for all non-listening ports). This analysis can be enhanced to<br />
determine the type of firewall used based on network packet tests.<br />
Is it a stateful firewall or is it an access list filter on a router? How is it<br />
configured? Can it be bypassed?<br />
Detecting a reverse proxy in front of the web server needs to be done<br />
by the analysis of the web server banner, which might directly disclose<br />
the existence of a reverse proxy (for example, if ‘WebSEAL’[1] is returned).<br />
It can also be determined by obtaining the answers given by<br />
the web server to requests and comparing them to the expected answers.<br />
For example, some reverse proxies act as “intrusion prevention<br />
systems” (or web-shields) by blocking known attacks targeted at the<br />
web server. If the web server is known to answer with a 404 message<br />
to a request that targets an unavailable page and returns a different<br />
error message for some common web attacks like those done by CGI<br />
scanners, it might be an indication of a reverse proxy (or an application-level<br />
firewall) which is filtering the requests and returning a different<br />
error page than the one expected. Another example: if the web<br />
server returns a set of available HTTP methods (including TRACE) but<br />
the expected methods return errors then there is probably something<br />
in between blocking them.<br />
In some cases, even the protection system gives itself away:<br />
GET /web-console/ServerInfo.jsp%00 HTTP/1.0<br />
HTTP/1.0 200<br />
Pragma: no-cache