Custom Error Pages

Implementing custom error pages allows you to effectively increase your security posture, as it secures your web applications from the unintentional leakage of information.

A well-executed error/exception handling strategy will increase your overall security posture by: 

• Limiting the unintentional leakage of sensitive information (which can be weaponized and used to attack the application)
• Limiting the possibility of a malicious actor using the information exposed in a social engineering exploit

While error messages contain useful information for a system administrator diagnosing network/application problems, the same information can be utilized by an attacker to tailor their attacks to the target network. Tailored attacks have a greater chance of success and therefore pose a significantly greater threat.  

This article will describe how to handle custom error pages in order to effectively secure your applications.

In This Article

• Handling Custom Error Pages
  • SQL Example
  • Microsoft VBScript Runtime Error
• Securing Your Applications
• Implementing Custom Error Pages

Handling Custom Error Pages

Custom error handling mitigates the leakage of sensitive information against a wide variety of attacks. However, the most pertinent may be SQL injections. SQL injections are substantially more difficult to execute without the help of some verbose error messages. With no prior knowledge of the database, attackers must rely on correctly guessing the SQL language used, table/column names, the number of columns, etc. This requires a significant number of attempts and is very noisy; it is possible that you will have had some of these attempts escalated to you by Alert Logic®. 

Attackers often begin with an untailored ‘blind’ injection where an attacker with no knowledge of the target systems employs a “hit and hope” strategy, where they try numerous queries in the hope that they get lucky and find one which elicits an informative response from the server. These are very noisy and have a low success rate. The following screenshot is an example of a ‘blind’ SQL injection via a GET request.

Additionally, blind injections are also used to force an application to error. The intention is to uncover information which can then be used to craft specialized attacks.

It is common for failed database queries to output the query that was attempted. Returning this publicly may result in attackers gaining information about your database’s structure. Some applications can output a stack trace when they fail. Returning this trace publicly may result in attackers gaining sensitive information about the system, such as what software is being used (file paths, the type of application, or language in use).

SQL Example

Below is an extract from a 500 error. The server references ORA-01017, which not only indicates that the SQL backend is processing the queries, but also informs the attacker of the SQL language used – Oracle.

Microsoft VBScript Runtime Error

Below is an example of a Microsoft VBScript runtime error where the last query has been returned. This is the last successful query run and was likely performed by a legitimate user. The attacker now has knowledge of specific column and table names. With a better understanding of the server’s configuration, an attacker can use this information to interact with the contents of the database.

It is important to remember that disclosure of sensitive information via error messages is not exclusive to SQL injections. This is only a single example used to illustrate the dangers.

Securing Your Applications

By reviewing error handling code, Alert Logic can ensure that the application fails safely under both expected and unexpected conditions and that no sensitive information is disclosed to the user when an error occurs. Below is an example of a customized error message, which was returned in a 404 not found response. Bear in mind that even the HTTP response code alone can disclose information, such as whether a resource exists. Alert Logic’s aim is to limit any further useful information from being disclosed.

 

Errors are necessary for troubleshooting and debugging. Therefore, all exceptions and errors will need to be logged. Network admins can review the logs while restricting access to others via appropriate ACLs. 

There are several ways to process these types of attacks and errors. Alert Logic has listed the recommended and non-recommended methods below.

Recommended

• Static: A static custom error page that returns the same type of response regardless of the attack. It may state this page could not be found.  
• One liner: An example of static; gives no information away, such as “Sorry an error occurred.”  
• Redirect: This is a custom error page that redirects to a safe page, such as your home page. 

Not recommended

• Detailed View: This response normally contains a stack trace or verbose error information. This is useful for administrators but can be abused by malicious actors.
• Default: This response will vary depending on the service and server used. Some default responses do include sensitive information while others may be sufficiently secure. Alert Logic still recommends using custom error pages to be certain that information is not exposed.  
• Execute URL: This option can be vulnerable to code execution.  

Implementing Custom Error Pages 

Below is a selection of links from the proprietors of popular web apps, containing instructions on how to implement custom errors for each.  

Note: Please be aware that these URLs redirect to a third-party website and you will be leaving the Alert Logic domain.

Tomcat: 

• Version 7.0: Tomcat - 7.0
• Version 8.0: Tomcat - 8.0
• OWASP: Installation of Apache Tomcat - Securing Tomcat

Nginx:

• Using SilverStripe: Silverstrip

Apache:

• Custom Error Pages 

IIS:

• VBScript, JavaScript, VB.NET and C# - HTTP Errors 

 ASP.Net:

• Visual Basic: Create custom error reporting