Securing ASP.Net configurations from being hacked

ASP.Net configurations are pretty easy to use and highly manageable feature. But this can lead up to many misconfigurations which would lead into high security vulnerabilities.  

ELMAH is a handy 3^rd party configuration tool that developers can use to log errors and other information. But bad configuration can be lead up to many loopholes in the security perspective of the application. In following sections I’m explaining how to avoid those misconfigurations.

Handling Errors and redirect properly

First and foremost, we need to enable the customErrors in the web.config file. This is mainly to prevent the yellow screen of death in the browser.

<customErrors mode ="On" defaultRedirect ="Error.aspx"/>

This would solve the YSD issue but it would reveal the error page path in the url section in the browser. To eliminate that, we need to use the redirect mode attribute as below.

<customErrors mode ="On" defaultRedirect ="Error.aspx" redirectMode="ResponseRedirect"/>

This would keep the existing url in the browser’s url section while it is getting redirected to the appropriate error page.

Disable Tracing

Tracing is a handy tool that developers are using to get a log of requests been made and to get information about trace log information.

When you go to the View Details section, you can view various details such as detailed request details, origin .Net framework info etc.. But most dangerously, there can be trace logs that developers have logged and forgot to remove in production code. To remove all these make sure that the following attribute is set to false.  

<trace enabled="false"/>

 

Encrypt config sections

We used to keep sensitive data such as connection string passwords in the web.config file. But leaving these sensitive data in plain text in anywhere is a high security vulnerability. There are many tools and methods where we can encrypt these sections and I’m going to discuss one of the easiest ways we can achieve it using regiis tool.

1. Run the command prompt in Admin mode


2. Browse to the .Net framework’s path > eg : C:\Windows\Microsoft.NET\Framework\v4.0.30319


3. Run the following command
   Aspnet_regiis –site “MySecureSite ” –app “/” –pe “ConnectionStrings”

Note : -app is the application folder relative to root of the IIS. In my case I hosted mySecureSite in the root.  –pe is the section we need to encrypt

After this you can see the given section is hashed.

Use the –pd attribute in same manner to decrypt the given section.

This may not the most appropriate way to encrypt the config sections but it is fairly easy.

Use config transforms

We can use the Web.Release.Config’s config transform to make sure we are not leaking out any dev related config entries to the production code. Following are two examples of how we can use it.

Following sections would make sure that error mode is remoteonly, the 500 error would redirected to a production error page and the trace attribute is removed.

Keep in mind that in order to take this into the action, we need to publish the web project.

 <customErrors mode="RemoteOnly" xdt:Transform="Replace">

      <error statusCode="500" redirect="InternalServeError.html"/>

    </customErrors>

    <trace xdt:Transform="Remove"/>

In the production environment, it is advisable to enable the retail mode in machine.config file.

<deployment retail="true"/>