1. Authentication
  1. Brute Force

  2. Insufficient Authentication

  3. Weak Password Recovery Validation

2. Authorization
  1. Credential/Session Prediction

  2. Insufficient Authorization

  3. Insufficient Session Expiration

  4. Session Fixation

3. Client-side Attacks
  1. Content Spoofing

  2. Cross-site Scripting

4. Command Execution
  1. Buffer Overflow
  2. Format String Attack
  3. LDAP Injection
  4. OS Commanding
  5. SQL Injection
  6. SSI Injection
  7. XPath Injection
5. Information Disclosure
  1. Directory Indexing

  2. Information Leakage

  3. Path Traversal

  4. Predictable Resource Location

6. Logical Attacks
  1. Abuse of Functionality

  2. Denial of Service

  3. Insufficient Anti-automation

  4. Insufficient Process Validation

Directory listing

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) 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 - 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 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 Nikto, 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.

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

- Backup files - with extensions such as .bak, .old or .orig
- Temporary files - these are files that are normally purged from the server but for some reason are still available
- Hidden files - with filenames that start with a "." period.
- 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...
- Enumerate User Accounts - personal user accounts on a web server often have home directories named after their user account.
- Configuration file contents - these files may contain access control data and have extentions such as .conf, .cfg or .config
- 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.

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 allow/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.


Directory Indexing Vulnerability Alerts

Nessus "Remote File Access" Plugin Web page

Web Site Indexer Tools

Intrustion Prevention for Web

Search Engines as a Security Threat
http://it.korea.ac.kr/class/2002/software/ Reading%20List/Search%20Engines%20as%20a%20Security%20Threat.pdf

The Google Hacker's Guide

To receive your Free Application Vulnerability Assessment for testing of one attack vulnerability of your choice, please submit your payment of $99.00 for a second Directory listing attack vulnerability test.

Business Name:
Contact Information:
Email Address:
URL or IP address:

Other members of our business group:
Cloud-Security.us | US-scada.com

COPYRIGHT (C) 2000 - 2013 InfoSecPro.com ALL RIGHTS RESERVED