Handling Verbose Error Message(Improper Error Handling) In Web.config

Improper error handling leads to a variety of security problems. Common problems include when we expose our internal methods in Stack-traces, error codes, exceptions etc. and these are displayed to the hacker. An attacker is one who is waiting for such a thing to show up in order to take advantage of it. Out of memory, null pointer, array out of bounds exception and hundreds of other errors are a common cause. We need to have a strong mechanism to handle these errors and hide implementation details from the attacker.

Verbose Error Message (Improper Error Handling)

Improper error handling leads to a variety of security problems. Common problems include when we expose our internal methods in Stack-traces, error codes, exceptions etc. and these are displayed to the hacker. An attacker is one who is waiting for such a thing to show up in order to  take advantage of it. Out of memory, null pointer, array out of bounds exception and hundreds of other errors are a common cause. We need to have a strong mechanism to handle these errors and hide implementation details  from the attacker.

 

Solution

Defining custom errors mode and its redirection in web.config file:

<system.web>
<customErrors mode="RemoteOnly" defaultRedirect="Error.aspx">
<error statusCode="401" redirect="SecurePage.aspx" />
<error statusCode="403" redirect="SecurePage.aspx" />
<error statusCode="404" redirect="NotFound.aspx" />
<error statusCode="500" redirect="Error.aspx" />
</customErrors>
</system.web>

Request Filtering is a built-in security feature that was introduced in Internet Information Services.

<security>
<requestfiltering allowdoubleescaping="true">
</requestfiltering>
</security>

Visit this link for detailed information:

 

Avoid displaying stack traces

<system.web>
<trace enabled="false" localOnly="true"/>
</system.web>

Debugging

<compilation debug="false" targetFramework="4.5">

When uploading, leaving debugging enabled is dangerous because you are providing inside information to an attacker who shouldn’t have access to it, and who may use it to attack your Web-based applications.

 

Disabling request validation(In the application as whole)

<configuration>
<system.web>
<pages validateRequest="false" />
</system.web>
</configuration>

Or at page level we can do it like this:

<@ Page validateRequest="false" %>

It prevents XSS.

 

Summary

We must enable and build substantial web apps by securing them in web config. However, the list is incomplete, but these are the strongest techniques to handle major threats. It’s always good to incorporate the necessary key security best practices during the designing phase thus ensuring the system is not at risk. I hope this article will definitely add some useful information to your dictionary. Good day!!