-
Sub-task
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
-
False
-
None
-
False
-
-
Follow these guidelines to create secure system or user error messages that reveal the minimum necessary amount of information about the cause of an error, and the internal status of a system:
- Use a global error handler to catch errors or exceptions not explicitly handled by the application.
- Analyze the return values of the functions when they contain information about the outcome of the operation. Do not ignore such values. For example a file creation object may return the status code of the operation and indicate the success or failure.
- Always provide remote systems/users with a generic error message that does not reveal internal system details, such as a stack trace, working directory, or core dump.
- Centralize the process of error message generation.
- A class or property-file can contain the text of all returned error messages with various parameters.
- Set application and server configurations to provide minimum details in error messages.
- Especially when an unhandled exception or error occurs that is not explicitly caught by the application. - For example, when an application server handles part of the messages before reaching your application.
- In some cases, the server may provide a facility to catch all errors before forwarding to the remote system.
- In other cases, the application will need to explicitly develop a handler that catches any errors before redirecting them to the remote system. - The advantage here is that the application can log the error with a unique ID, create a generic message to the remote system, and include the unique ID in the response. - This allows application support personnel to troubleshoot an issue without revealing system details to remote systems.
- Do not explicitly specify the underlying reason for an error when a number of reasons could have caused it.
- This is especially important when that information could be used for more directed attacks. - A typical example is returning different errors for wrong usernames or wrong passwords, which allows for __user enumeration__ attacks.
- Do not include any sensitive data in error messages.
- This is especially important when error messages are logged.
- Sign and encrypt detailed error messages when they are required by a specific remote system.
- Use a set of mutual keys to encrypt the information. - The receiving system can also request a signature and verify the signature to verify the authenticity of the errors.
Imported from SD Elements: https://redhat.sdelements.com/bunits/psse-secure-development/group-2-extended-functionality-offerings/amq-clients/tasks/phase/specifications/141-T159/
How Tos:
ASP.NET Core / C#: Generic Default Error Page
Description
This code sample shows how to configure your application to hide error messages from users and to redirect them to a customized HTML error page for each error number. You make changes to the Startup class's Configure() method.
For example, if the application receives error 401, Unauthorized, it redirects them to an error page. In this case, use a dynamically created page, but you can use a static page too. In either case, just be sure not to reveal any information that could help hackers plan an attack.
Code
app.UseStatusCodePagesWithRedirects("/error/{0}"); // Map proper path to each error number. E.g. /error/404 app.Map("/error", error => { error.Run(async context => { var builder = new StringBuilder(); // You can build the customized HTML error page for each error number instead of returning error details. builder.AppendLine("<html><body>"); builder.AppendLine("An error occurred.<br />"); var path = context.Request.Path.ToString(); if (path.Length > 1) { builder.AppendLine("Status Code: " + HtmlEncoder.Default.Encode(path.Substring(1)) + "<br />"); } builder.AppendLine("</body></html>"); context.Response.ContentType = "text/html"; await context.Response.WriteAsync(builder.ToString()); }); });
Now that you have secured the error pages that your site visitors will see, implement exception handling for developers.
**`
if (env.IsDevelopment())
else
{ app.UseExceptionHandler("/error"); }**`
Training Modules
Defending Web APIs
Defending Web Applications
- User Enumeration
- Information Disclosure Vulnerabilities
- Monitoring Logs
- Sensitive Data in Logs
- Defending Against Insecure Logging Attacks