• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!


Directory Indexing

Page history last edited by Robert Auger 14 years, 6 months ago

Project: WASC Threat Classification

Threat Type: Weakness

Reference ID: WASC-16


Directory Indexing

Automatic directory listing/indexing is a web server function that lists all of the files within a requested directory if the normal base file (index.html/home.html/default.htm/default.asp/default.aspx/index.php) is not present. When a user requests the main page of a web site, they normally type in a URL such as: http://www.example.com/directory1/ - using the domain name and excluding a specific file. The web server processes this request and searches the document root directory for the default file name and sends this page to the client. If this page is not present, the web server will dynamically issue a directory listing and send the output to the client. Essentially, this is equivalent to issuing an "ls" (Unix) or "dir" (Windows) command within this directory and showing the results in HTML form. From an attack and countermeasure perspective, it is important to realize that unintended directory listings may be possible due to software vulnerabilities (discussed in the example section below) combined with a specific web request.



When a web server reveals a directory's contents, the listing could contain information not intended for public viewing. Often web administrators rely on "Security Through Obscurity" assuming that if there are no hyperlinks to these documents, they will not be found, or no one will look for them. The assumption is incorrect. Today's vulnerability scanners, such as Wikto, can dynamically add additional directories/files to include in their scan based upon data obtained in initial probes. By reviewing the /robots.txt file and/or viewing directory indexing contents, the vulnerability scanner can now interrogate the web server further with these new data. Although potentially harmless, Directory Indexing could allow an information leak that supplies an attacker with the information necessary to launch further attacks against the system.


Example Request and Response

Client issues a request for - http://www.example.com/admin/ and receives the following dynamic directory indexing content in the response -


Index of /admin
Name                    Last modified      Size  Description
Parent Directory                             -   
backup/                 31-Mar-2003 08:18    -   
Apache/2.0.55 Server at www.example.com Port 80

As you can see, the directory index page shows that there is a sub-directory called "backup". There is no direct hyperlink to this directory in the normal html webpages however the client has learned of this directory due to the indexing content. The client then requests the backup directory URL and receives the following output -


Index of /admin/backup
Name                    Last modified       Size  Description
Parent Directory        10-Oct-2006 01:20      -  
WS_FTP.LOG              18-Jul-2003 14:59     4k  
db_dump.php             18-Jul-2003 14:59     2k  
dump.txt                28-Jun-2007 20:30    59k  
dump_func.php           18-Jul-2003 14:59     5k  
restore_db.php          18-Jul-2003 14:59     4k  
Apache/2.0.55 Server at www.example.com Port 80

As you can see, there is sensitive data within this directory (such as DB dump data) that should not be disclosed to clients. Also note that files such as WS_FTP.LOG can provide directory listing information as this file lists client and server directory content transfer data. An example WS_FTP.LOG file may look like this -


 101.08.27 17:56 B C:\unzipped\admin\backup\db_dump.php --> /public_html/admin/backup db_dump.php
101.08.27 17:56 B C:\unzipped\admin\backup\dump.txt --> /public_html/admin/backup dump.txt
101.08.27 17:56 B C:\unzipped\admin\backup\dump_func.php --> /public_html/admin/backup dump_func.php
101.08.27 17:56 B C:\unzipped\admin\backup\restore_db.php --> /public_html/admin/backup restore_db.php
101.08.27 18:02 B C:\unzipped\admin\backup\db_dump.php --> /public_html/admin/backup db_dump.php

Example Information Disclosed

The following information could be obtained based on directory indexing data:


  1. Backup files - with extensions such as .bak, .old or .orig
  2. Temporary files - these are files that are normally purged from the server but for some reason are still available
  3. Hidden files - with filenames that start with a "." period.
  4. Naming conventions - an attacker may be able to identify the composition scheme used by the web site to name directories or files. Example: Admin vs. admin, backup vs. back-up, etc...
  5. Enumerate User Accounts - personal user accounts on a web server often have home directories named after their user account.
  6. Configuration file contents - these files may contain access control data and have extentions such as .conf, .cfg or .config
  7. Script Contents - Most web servers allow for executing scripts by either specifying a script location (e.g. /cgi-bin) or by configuring the server to try and execute files based on file permissions (e.g. the execute bit on *nix systems and the use of the Apache XBitHack directive). Due to these options, if directory indexing of cgi-bin contents are allowed, it is possible to download/review the script code if the permissions are incorrect.


Example Attack Scenarios

There are three different scenarios where an attacker may be able to retrieve an unintended directory listing/index:


  1. The web server is mistakenly configured to provide a directory index. Confusion may arise of the net effect when a web administrator is configuring the indexing directives in the configuration file. It is possible to have an undesired result when implementing complex settings, such as wanting to allow directory indexing for a specific sub-directory, while disallowing it on the rest of the server. From the attacker's perspective, the HTTP request is identical to the previous one above. They request a directory and see if they receive the desired content. They are not concerned with or care "why" the web server was configured in this manner.
  2. Some components of the web server allow a directory index even if it is disabled within the configuration file or if an index page is present. This is the only valid "exploit" example scenario for directory indexing. There have been numerous vulnerabilities identified on many web servers, which will result in directory indexing if specific HTTP requests are sent.
  3. Google' cache database may contain historical data that would include directory indexes from past scans of a specific web site. For specific examples of Google capturing directory index data, please refer to the "Sensitive Directories" section of the Google Hacking Database - http://johnny.ihackstuff.com/ghdb.php?function=summary&cat=6





[1] http://www.sensepost.com/research/wikto/using_wikto.pdf


Directory Indexing Vulnerability Alerts

[2] http://www.securityfocus.com/bid/1063

[3] http://www.securityfocus.com/bid/6721

[4] http://www.securityfocus.com/bid/8898


Nessus "Remote File Access" Plugin Web page

[5] http://cgi.nessus.org/plugins/dump.php3?family=Remote%20file%20access


The Google Hacker's Guide

[6] http://johnny.ihackstuff.com/security/premium/The_Google_Hackers_Guide_v1.0.pdf


Information Leakage

[7] http://projects.webappsec.org/Information-Leakage


Information Leak Through Directory Listing

[8] http://cwe.mitre.org/data/definitions/548.html

Comments (0)

You don't have permission to comment on this page.