Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Section
Column
width1200px

 

Note

Handled and unhandled errors

The error pages should be consistent throughout the whole system. Configuring different error pages for handled errors and unhandled errors (a page redirected by ASP.NET using the <customErrors> web.config key) can be a severe security risk.

You should have only one error page for both of these cases. Find more information in the Creating custom error handling pages topic.

Time based errors

The time needed for processing a page after encountering an error can be considerably different from the processing time in other cases. The attackers can use this difference to guess if their input has caused any problems in the system.

There is no general recommendation on how to solve this trouble. However, you can try to provide some malicious input yourself and observe how much time it takes the system to complete the request. This way, you can find weaknesses in the system.

Storing the debug and trace information in the event log

Instead of showing detailed information about the problem in the error message, store the debug data and stack trace into the event log. The following example logs an event in the event log:

Code Block
languagecsharp
private void LogEvent(Exception ex)
{
     // Logs an error type event
	 EventLogProvider.LogEvent(EventType.ERROR, "API Example", "APIEXAMPLE", eventDescription: "An error happened. Message: " ex.Message + ", StackTrace:" + ex.StackTrace);
}

Configuring the error messages

To configure the system to display custom error messages, modify the web.config file, as described in the Web.config file settings topic.

Disabling debugging and tracing

Disabling debugging and tracing for your ASP.NET application
Column