4.0

47Web Application Penetration Testingframework-specific folders• Do not use default scripts on the page or obfuscate them if theymust be used.Specific files and foldersGeneral guidelines:• Remove any unnecessary or unused files on the server. This impliestext files disclosing information about versions and installation too.• Restrict access to other files in order to achieve 404-response whenaccessing them from outside. This can be done, for example, by modifyinghtaccess file and adding RewriteCond or RewriteRule there. Anexample of such restriction for two common WordPress folders is presentedbelow.RewriteCond %{REQUEST_URI} /wp-login\.php$ [OR]RewriteCond %{REQUEST_URI} /wp-admin/$RewriteRule $ /http:/your_website [R=404,L]However, these are not the only ways to restrict access. In order toautomate this process, certain framework-specific plugins exist. Oneexample for WordPress is StealthLogin (http:/wordpress.org/plugins/stealth-login-page).Additional approachesGeneral guidelines:[1] Checksum managementThe purpose of this approach is to beat checksum-based scannersand not let them disclose files by their hashes. Generally, there are twoapproaches in checksum management:• Change the location of where those files are placed (i.e. move themto another folder, or rename the existing folder)• Modify the contents - even slight modification results in a completelydifferent hash sum, so adding a single byte in the end of the fileshould not be a big problem.[2] Controlled chaosA funny and effective method that involves adding bogus files andfolders from other frameworks in order to fool scanners and confusean attacker. But be careful not to overwrite existing files and foldersand to break the current framework!Map Application Architecture (OTG-INFO-010)SummaryThe complexity of interconnected and heterogeneous web server infrastructurecan include hundreds of web applications and makes configurationmanagement and review a fundamental step in testing anddeploying every single application. In fact it takes only a single vulnerabilityto undermine the security of the entire infrastructure, and evensmall and seemingly unimportant problems may evolve into severerisks for another application on the same server.To address these problems, it is of utmost importance to perform anin-depth review of configuration and known security issues. Beforeperforming an in-depth review it is necessary to map the network andapplication architecture. The different elements that make up the infrastructureneed to be determined to understand how they interactwith a web application and how they affect security.How to TestMap the application architectureThe application architecture needs to be mapped through some testto determine what different components are used to build the webapplication. In small setups, such as a simple CGI-based application, asingle server might be used that runs the web server which executesthe C, Perl, or Shell CGIs application, and perhaps also the authenticationmechanism.On more complex setups, such as an online bank system, multipleservers might be involved. These may include a reverse proxy, a frontendweb server, an application server and a database server or LDAPserver. Each of these servers will be used for different purposes andmight be even be divided in different networks with firewalls betweenthem. This creates different DMZs so that access to the web serverwill not grant a remote user access to the authentication mechanismitself, and so that compromises of the different elements of the architecturecan be isolated so that they will not compromise the wholearchitecture.Getting knowledge of the application architecture can be easy if thisinformation is provided to the testing team by the application developersin document form or through interviews, but can also prove tobe very difficult if doing a blind penetration test.In the latter case, a tester will first start with the assumption thatthere is a simple setup (a single server). Then they will retrieve informationfrom other tests and derive the different elements, questionthis assumption and extend the architecture map. The tester will startby asking simple questions such as: “Is there a firewalling system protectingthe web server?”. This question will be answered based on theresults of network scans targeted at the web server and the analysisof whether the network ports of the web server are being filteredin the network edge (no answer or ICMP unreachables are received)or if the server is directly connected to the Internet (i.e. returns RSTpackets for all non-listening ports). This analysis can be enhanced todetermine the type of firewall used based on network packet tests.Is it a stateful firewall or is it an access list filter on a router? How is itconfigured? Can it be bypassed?Detecting a reverse proxy in front of the web server needs to be doneby the analysis of the web server banner, which might directly disclosethe existence of a reverse proxy (for example, if ‘WebSEAL’[1] is returned).It can also be determined by obtaining the answers given bythe web server to requests and comparing them to the expected answers.For example, some reverse proxies act as “intrusion preventionsystems” (or web-shields) by blocking known attacks targeted at theweb server. If the web server is known to answer with a 404 messageto a request that targets an unavailable page and returns a differenterror message for some common web attacks like those done by CGIscanners, it might be an indication of a reverse proxy (or an application-levelfirewall) which is filtering the requests and returning a differenterror page than the one expected. Another example: if the webserver returns a set of available HTTP methods (including TRACE) butthe expected methods return errors then there is probably somethingin between blocking them.In some cases, even the protection system gives itself away:GET /web-console/ServerInfo.jsp%00 HTTP/1.0HTTP/1.0 200Pragma: no-cache