A full path disclosure (FPD) attack is pretty well-defined by its name. The attack, if successful, discloses the “full path” to a resource on the web server. That, in itself, may not be enough to compromise the network. But with the disclosed information, an attacker could mount a path traversal attack, which, if successful, would grant the attacker access to sensitive files stored on the server.

A full path disclosure attack can be understood as an information disclosure vulnerability. The consequences of information disclosure vulnerabilities can be evident in some cases and more subtle in others, based on the nature of the compromised web server (is it an online store or messaging service?) and the information the attacker was able to access. So, for example, disclosing the credit card numbers of a web store’s customers has immediate consequences for both the web store itself and its users.

But many times, the disclosed information will be of less immediate value, as in a full path disclosure attack. Leaking technical information such as the directory structure of the web server may have little or no direct impact. But such information can be used to mount other – potentially severe – online attacks by chaining together a full path disclosure attack and a path traversal attack, for example, as we’ll see a bit later.

Risks of full path disclosure attacks

Full path disclosure attacks can reveal the following information to the attacker:

  • The names, structure, and contents of hidden directories
  • The locations of configuration files, databases, and other sensitive files
  • Hard-coded API keys, IP addresses, database credentials, etc.
  • The existence or absence of resources, usernames, etc.

How do full path disclosure attacks work?

In a full path disclosure attack, the attacker purposefully sends malformed commands to the server in the hopes that

  • The server will respond with an error message
  • The error message will contain valuable information, as in the above list

From there, the attacker would use the information gleaned in the full path disclosure attack to mount a second attack that may grant them access to the actual files/resources, such as a path traversal attack. In a path traversal attack, the attacker could even upload or create files to/on the server, modify application data, and ultimately take over the server.

Every little bit counts

The error messages triggered by full path disclosure attacks can also reveal the underlying operating system. An attacker can distinguish Unix-based operating systems from Windows by looking at the file paths. Windows file paths always start with a drive-letter (e.i., C:), while Unix-based operating systems tend to start with a single front slash (/home/whatever/…).

A Unix example:

Warning: session_start() [function.session-start]: The session id contains illegal characters, valid characters are a-z, A-Z, 0-9 and ‘-,’ in /home/John/public_html/includes/functions.php on line 2

A Windows example:

Warning: session_start() [function.session-start]: The session id contains illegal characters, valid characters are a-z, A-Z, 0-9 and ‘-,’ in C:\Users\Mary\public_html\includes\functions.php on line 2

Taking a closer look, the error messages in the above examples reveal more than just the underlying operating system. The examples above also disclose the usernames of two users on the operating systems, John and Mary. Things such as usernames (and, of course, passwords) add to the attacker’s toolkit. Armed with valid credentials, attackers could mount a variety of additional attacks.

Full path disclosure attack examples

Triggering server error messages using an empty array

Suppose a website uses the method shown below to request a web page:

http://website.com/index.php?page=about

An attacker could add opening and closing brackets to the URL and trigger an error message from the server. The attacker would send:

http://website.com/index.php?page[]=about

And the server would respond with the following error message:

Warning: opendir(Array): failed to open dir: No such file or directory in /home/omg/htdocs/index.php on line 84

Warning: pg_num_rows(): supplied argument … in /usr/home/website/html/pie/index.php on line 131

With that, the attacker knows the structure of the server’s webroot, the location of the index.php file, as well as some knowledge about its contents.

Combining full path disclosure and pass traversal attacks

A popular method of triggering server errors in a full path disclosure attack is to send the server null or invalid session cookies through JavaScript injection:

  • javascript:void(document.cookie=“PHPSESSID=");
  • javascript:void(document.cookie=‘PHPSESSID=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA’);
  • javascript:void(document.cookie=‘PHPSESSID=.’);

The above three examples all represent a null (example 1) or invalid (example 2 & 3) session cookie and would result in the following error message:

javascript:void(document.cookie=“PHPSESSID=");

javascript:void(document.cookie=‘PHPSESSID=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA’);

javascript:void(document.cookie=‘PHPSESSID=.’);

Warning: session_start(): The session id is too long or contains illegal characters,valid characters are a-z, A-Z, 0-9 and ‘-,’ in /home/website/public_html/includes/functions.php on line 2

This gives the attacker knowledge of the server’s webroot, the location of the functions.php file, and – if they know their stuff – the location of the config.php file (typically in the same directory as the functions.php file).

With that knowledge in hand, the attacker can test the server to see if it allows unprotected use of the show.asp function. Unprotected use here would mean that the server does not validate the input or perform whitelist checks when dealing with files or directories that come from user-controlled input.

So the attacker can send the following request to the server:

http://website.com/show.asp?view=homepage.html

When a user accesses the URL through a web browser, the server receives a request for the page associated with the show.asp function. In this case: view=homepage.html. The server then sends the requested page – the homepage. This tells the attacker that the website does not validate user input and hence that by using the show.asp function, they can access any file provided in the URL’s view parameters.

The attacker crafts a URL with either a relative file path (using ../, for example: https://www.website.com/download_file.php?file=../../etc/passwd) or an absolute file path (directly referencing the file location, for example: http://website/get.asp?f=/etc/passwd) that requests the /etc/passwd file.

Because the server doesn’t validate user input, the attacker can break out of the webroot and access critical system files. In our example, that’s the passwd file. With access to the contents of the server’s passwd file, an attacker may well be able to take control of the server.

How to defend against full path disclosure attacks?

The way to protect your web server from full path disclosure attacks is actually relatively straightforward. It’s done by editing the php.ini file of your server to either:

  • Disable error reporting:

error_reporting(0);

  • Hide error messages:

display_errors(0);

However, even though you’ve disabled or hidden your server’s error reporting, it could still be vulnerable to all sorts of information disclosure attacks. So if you really want to secure your web server, you should also do the following. All of the measures listed below are easy to apply and will take you a long way toward securing your web server from unwanted disclosures.

Defending against information disclosures at large

Sanitize your headers

You want to ensure that your web server does not send out response headers or background information that reveals sensitive technical details about your web server, such as the backend technology type, version, or configuration.

Sanitize user input

Treat input from authenticated, internal, and public users the same way: don’t trust it, sanitize it. Make sure that your web application sanitizes user input properly and that a generic response is always returned for every resource that doesn’t exist or that is disallowed.

Sanitize Filename Parameters

The safest approach would be to disallow file access from user input. However, that may not be a viable option for many, if not most, web applications out there. If you need to allow access to files from user input, ensure that the input is properly validated and that the server bars access to restricted files or directories. Disallow user-supplied data as a filename or part of the filename when performing operations on files or folders. If the filename needs to be set by the user, use predefined conditions rather than direct input.

Handle exceptions gracefully

The above also applies to exceptions. You should ensure that no technical information appears in the error messages when exceptions occur and the web application fails.

Silence your services

You also want to ensure that any services running on the server’s open ports do not disclose sensitive technical information, such as their build and version numbers.

Implement the principle of least privilege

The principle of least privilege is an IT security policy that states that you should only assign the minimum necessary rights to a user that requires access to a resource. The principle also states that those rights should be in effect for the shortest possible duration.

Make sure only to provide users with the minimum necessary permissions to legitimately interact with the webserver/application.

Use access control lists (ACL)

Access control lists impose limits to the permissions you grant your users. Make sure your organization sets up and uses ACLs, as those limited permissions will also apply to your attacker if they manage to compromise one of your users’ accounts. That could save you from a headache or two.

Never hardcode sensitive information

Credentials, API keys, IP addresses, or any other sensitive information should never be hard-coded in your web application’s source code, such as first names and last names. And don’t forget that this applies to comments within the code too.

Hard-code allowed file extensions

Make sure to provide access to allowed file extensions only. You can hard-code allowed file extensions as shown below:

Disallow directory listing

You want to configure your web server to disallow directory listing and display a generic web page instead. On Apache, this is achieved by adding the following to your .htaccess file:

<Directory /{YOUR DIRECTORY}>  Options FollowSymLinks

Sandboxing

It’s also recommended to use sandbox environments (i.e., jail, chroot) that enforce strict boundaries between the processes and the operating system.

Stick to what you need (and nothing more)

Uploaded files should be restricted to those necessary to your web application. Nothing else should ever be uploaded on the web server – they may well have unintended consequences.

Always check whether each request to create/edit/view/delete resources has proper access controls, preventing privilege escalation issues and ensuring that all the confidential information remains confidential.

Keep your systems updated

Make sure your web server software is up-to-date with the most recent security patches. And always install them as soon as possible. You don’t want to fall victim to known vulnerabilities.

Wrap up

So a full path disclosure attack is more of an entry point to attacks with bigger and more sensitive payloads. Hardening your server to mitigate full path disclosure attacks is a crucial first step. But it’s the first step. It’s highly recommended to go the extra mile and defend not just against full path disclosure attacks but also against the attacks FPD enables. The above tips will help you secure your server and, hopefully, will prevent you from falling victim to information disclosure attacks in general.

Stay safe (and keep your paths to yourself).