Information can be a valuable tool, especially when it comes to security which is why knowing the absolute path of a file can be a dangerous thing. Full path disclosure (FPD) occurs when an application reveals the absolute or full path of a file. On it’s own simply knowing the absolute path would not be overly harmful although this can be paired with other vulnerabilities such as SQL injection or local file inclusion to create a far more dangerous attack.
To aid in application development the absolute path of a file can be revealed within error messages, however, if error messages have not been turned off when the application goes live then an attacker may be able to force an application error to reveal the full path. An example of how an attacker may force an application error would be to change the data type of a URL parameter from a string to array. I’ll provide an example of this below.
https://vulnerable-website.com/profile.php?name=SandraAs you can see in the example above, the URL has a parameter called name, this is given a string (word) value of Sandra. It’s likely this value is being passed to underlying functionality which is where an error can often be produced. Lets say the website is using PHP’s urldecode() function, this function is expecting a simple string. If we change this to an “Array” (list of strings) then it will not be able to process this and so produces an error. An attacker may change the type of data by simply adding squared brackets [] before the equals symbol =, here’s an example.
https://vulnerable-website.com/profile.php?name[]=SandraShould the web page produce an error then the attacker would most likely see something similar to that which is below, as you can see the pages absolute path has been provided.
Fatal error: Uncaught TypeError: urldecode(): Argument #1 ($string) must be of type string, array given in /opt/lampp/htdocs/profile.php:20Here are some other error messages that webpages commonly produce with this kind of attack. Please note, these errors are specific to PHP and so your mileage may vary.
Fatal error: Uncaught TypeError: Argument 1 passed to str_contains() must be of the type string, array given
Fatal error: Uncaught TypeError: unserialize(): Argument #1 ($data) must be of type string, array given in /opt/lampp/htdocs/profile.php:20It’s important to note, full path disclosure can occur in many situations which is why we recommend following the steps below along with any practices specified within your respective documentation.
Full path disclosure through API error handling
The use of application programming interfaces or APIs has become more common because they allow a convenient way for applications to retrieve data through a single location. However, it’s somewhat common for a full path disclosure vulnerability to occur within these APIs as developers often forget that the user can still manipulate the data being provided and produce an error.
A website would usually interact with an API by sending data in a specific format, one such format would be JSON. When the API retrieves the data which has been provided, the very first thing it will do is try to read this by changing it into a format it is more familiar with, most modern programming languages have this kind of functionality built in. If the API is expecting JSON data and specific checks haven’t been implemented by the developer then there is an opportunity for an attacker to have the API produce an error.
We know the API is expecting JSON data, so what happens if we provide some JSON data which isn’t valid? Well, as the data provided isn’t valid this means the API won’t be able to read this and it will produce an error, this error is often returned rather than the expected data. Invalid JSON can be as simple as adding an additional quotation “ which is why it’s important for developers to catch any exceptions (errors) within their code.
Protecting against full path disclosure
Protecting against full path disclosure can be as simple as disabling error messages on any application in a production environment. At the very least, if you’d like to enable some form of debugging then you could use custom errors messages which do not give out such information.
• In PHP error messages can be disabled by using the error_reporting() function.
• In Python’s Django framework you can disable debugging mode by specifying that DEBUG equal to False within the settings file.
• For further technologies and frameworks we strongly recommend referring to the provided documentation.
