4.0

56Web Application Penetration Testingnot disclose source code when accessed, they might yield valuableinformation in case they cause errors when invoked.Information obtained through server vulnerabilities and misconfigurationThe most obvious way in which a misconfigured server may discloseunreferenced pages is through directory listing. Request allenumerated directories to identify any which provide a directorylisting.Numerous vulnerabilities have been found in individual web serverswhich allow an attacker to enumerate unreferenced content,for example:• Apache ?M=D directory listing vulnerability.• Various IIS script source disclosure vulnerabilities.• IIS WebDAV directory listing vulnerabilities.Use of publicly available informationPages and functionality in Internet-facing web applications thatare not referenced from within the application itself may be referencedfrom other public domain sources. There are various sourcesof these references:• Pages that used to be referenced may still appear in the archivesof Internet search engines. For example, 1998results.asp mayno longer be linked from a company’s website, but may remainon the server and in search engine databases. This old script maycontain vulnerabilities that could be used to compromise theentire site. The site: Google search operator may be used to runa query only against the domain of choice, such as in: site:www.example.com. Using search engines in this way has lead to abroad array of techniques which you may find useful and thatare described in the Google Hacking section of this Guide. Checkit to hone your testing skills via Google. Backup files are not likelyto be referenced by any other files and therefore may have notbeen indexed by Google, but if they lie in browsable directoriesthe search engine might know about them.• In addition, Google and Yahoo keep cached versions of pagesfound by their robots. Even if 1998results.asp has been removedfrom the target server, a version of its output may still be storedby these search engines. The cached version may containreferences to, or clues about, additional hidden content that stillremains on the server.• Content that is not referenced from within a target applicationmay be linked to by third-party websites. For example, anapplication which processes online payments on behalf of thirdpartytraders may contain a variety of bespoke functionalitywhich can (normally) only be found by following links within theweb sites of its customers.File name filter bypassBecause blacklist filters are based on regular expressions, one cansometimes take advantage of obscure OS file name expansionfeatures in which work in ways the developer didn’t expect. Thetester can sometimes exploit differences in ways that file namesare parsed by the application, web server, and underlying OS andit’s file name conventions.Example: Windows 8.3 filename expansion “c:\program files” becomes“C:\PROGRA~1”– Remove incompatible characters– Convert spaces to underscores- Take the first six characters of the basename– Add “~” which is used to distinguish files with namesusing the same six initial characters- This convention changes after the first 3 cname ollisions– Truncate file extension to three characters- Make all the characters uppercaseGray Box TestingPerforming gray box testing against old and backup files requires examiningthe files contained in the directories belonging to the set ofweb directories served by the web server(s) of the web applicationinfrastructure. Theoretically the examination should be performed byhand to be thorough. However, since in most cases copies of files orbackup files tend to be created by using the same naming conventions,the search can be easily scripted. For example, editors leave behindbackup copies by naming them with a recognizable extension orending and humans tend to leave behind files with a “.old” or similarpredictable extensions. A good strategy is that of periodically schedulinga background job checking for files with extensions likely to identifythem as copy or backup files, and performing manual checks as wellon a longer time basis.Tools• Vulnerability assessment tools tend to include checks to spot webdirectories having standard names (such as “admin”, “test”, “backup”,etc.), and to report any web directory which allows indexing. If youcan’t get any directory listing, you should try to check for likely backupextensions. Check for example Nessus (http:/www.nessus.org),Nikto2(http:/www.cirt.net/code/nikto.shtml) or its new derivativeWikto (http:/www.sensepost.com/research/wikto/), which alsosupports Google hacking based strategies.• Web spider tools: wget (http:/www.gnu.org/software/wget/,http:/www.interlog.com/~tcharron/wgetwin.html); Sam Spade(http:/www.samspade.org); Spike proxy includes a web site crawlerfunction (http:/www.immunitysec.com/spikeproxy.html); Xenu(http:/home.snafu.de/tilman/xenulink.html); curl (http:/curl.haxx.se). Some of them are also included in standard Linux distributions.• Web development tools usually include facilities to identify brokenlinks and unreferenced files.RemediationTo guarantee an effective protection strategy, testing should be compoundedby a security policy which clearly forbids dangerous practices,such as:• Editing files in-place on the web server or application server filesystems. This is a particular bad habit, since it is likely to unwillinglygenerate backup files by the editors. It is amazing to see how oftenthis is done, even in large organizations. If you absolutely need toedit files on a production system, do ensure that you don’t leavebehind anything which is not explicitly intended, and consider thatyou are doing it at your own risk.• Check carefully any other activity performed on file systemsexposed by the web server, such as spot administration activities.For example, if you occasionally need to take a snapshot of a coupleof directories (which you should not do on a production system), you