Hacker’s Perspective: Web App Vulnerabilities – Detailed Error Messages

Detailed Error Messages – One Man’s Trash, Another Man’s Treasure

Web applications across the Internet often do not limit the data revealed in their error messages. These errors can reveal sensitive information like server paths, source code, internal IP addresses, and running services.

Though some developers and site admins disregard error messages as unimportant and of no substantial value to an attacker, this information can greatly change the outcome of a penetration test, and even result in complete compromise of the application.

Typically, error messages occur when arbitrary user input is provided to the application. This input can be a malformed date, a letter instead of a number, or even a simple apostrophe (‘) character.

Once the error message is triggered, the attacker must then determine whether any sensitive information is leaked within it. This information varies from application to application and is often a treasure trove of valuable data to an attacker.

Why Does it Matter?

Error messages revealing application data are valuable because they allow an attacker to gain a better understanding of the website, such as its services and even source. For example, the following screenshot displays an error that leaks the IP address of a SQL database:

Additionally, the below screenshot shows a user’s password:

While these are rather obvious security vulnerabilities, error messages often appear to contain less-damaging data.

For example, a leaked server path (“/var/www/site_name”) may appear harmless but could be the difference between a successful web shell upload and an unexploitable vulnerability. The server path could also reveal publicly exposed filenames that the attacker would otherwise never find.

An example of this kind of error message that appears benign can be seen in the below screenshot from a GraphQL request:

At first glance, it appears to be void of anything sensitive or internal. However, an attacker can abuse GraphQL’s field suggestion feature to gain more insight into the API schema. By attempting to guess field names, an attacker can fuzz the application and reveal objects to fetch additional sensitive information.

How Can You Fix It?

Detailed error messages can be a dangerous resource for attackers. If they exist within your application, they should be reduced to reveal as little information as possible to end users.

For example, an internal server error should reveal no more than the 500-error code and a brief message stating something went wrong, rather than detailed stack traces or SQL queries.

We recommend every web application conduct an annual penetration test to ensure that error messages are restricted, and that attackers have no way of gathering information related to the application or server.