Securing Your ASP.NET Application
Tags: aspnet, csharp, security
Published: 2017-09-16 23:53:17

---
title: Securing Your ASP.NET Application
published: true
description: Simple tips on securing your ASP.NET application
tags: aspnet, csharp, security
---

### Security is a pretty important topic in software development. When developing software it is easier to leave your application insecure and open to attacks than to take security measures. Sometimes, I am guilty of slacking off when it comes to security. ðŸ˜…ðŸ˜…

In this article, I'll be using the ASP.NET MVC template as the talking point. The MVC template is very weak/vulnerable, security-wise. One can say the template favors simplicity over security.

### Here are a couple of tips on how to secure your ASP.NET MVC application

#### 1. Hash passwords
I know this is sort of an obvious practice in software development. However, I still feel the need to mention it. Hashing passwords is a very crucial part of authentication, but quite an easy one to forget, especially if you're writing your own custom authentication code.

Also, choice of hashing algorithm is important. NEVER use MD5 to hash passwords, MD5 is super-easy to crack.ðŸ˜’ðŸ˜’ 

#### 2. Use strong password validation logic
Try to make your password validation as 'strong' as possible. Below is my personal favourite when it comes to password validation.

```aspnet
UserManager.PasswordValidator = new PasswordValidator
{
    RequiredLength = 6,
    RequireNonLetterOrDigit = true,
    RequireDigit = true,
    RequireLowercase = true,
    RequireUppercase = true,
};
```
#### 3. Brief authentication error messages
Make your authentication error messages as short as possible. For example, on login failure, your error message should read "username/password invalid" rather than specify which is invalid, because that'd give enough information to a potential hacker.

Also, in password reset, if the entered email doesn't exist in the system, rather than return an error message, display a success page.

#### 4. Turn on custom errors
By default the template shows full stack trace of exceptions whenever an error occurs. This is very sensitive information that should be hidden. This can be done from the web.config file by adding the custom errors tag and setting its mode to on.
```XML
<system.web>
    <customErrors mode="On"></customErrors>
</system.web>
```
#### 5. Secure your cookies! 
By default, the template's cookies can be accessed by JavaScript from other sites. These cookies can also be sent unencrypted over the wire. This can be fixed by adding the httpcookies tag to the web.config file.
```XML
<system.web>
    <httpCookies httpOnlyCookies="true" requireSSL="false"/>
</system.web>
```
If you're using SSL on your site, then requireSSL should be set to true.

#### 6. Get rid of needless headers!
By default the template sends a couple of HTTP headers with every request. These headers contain sensitive information such as the server type, ASP.NET version and MVC version. We can fix this by setting enableVersionHeader setting to false.

```XML
<system.web>
    <httpRuntime targetFramework="4.5.2" enableVersionHeader="false"/>
</system.web>
```
After doing this, we clear custom headers
```XML
<system.webServer>
    <httpProtocol>
        <customHeaders>
            <clear />
        </customHeaders>
    </httpProtocol>
</system.webServer>
```
#### 7. Rename your cookies.
In the MVC template, there are three basic cookies: the Application cookie, the Antiforgery Token and the Session cookie. We should rename these cookies to make the type of server we're using unknown to the user.
###### Renaming the session cookie
```XML
<system.web>
    <sessionState cookieName="custom_name" />
</system.web>
```
###### Renaming the Antiforgery token
This is done in the Global.asax.cs file
```aspnet
protected void Application_Start()
        {
            AreaRegistration.RegisterAllAreas();
            FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
            RouteConfig.RegisterRoutes(RouteTable.Routes);
            BundleConfig.RegisterBundles(BundleTable.Bundles);
            //added line
            ConfigureAntiForgeryTokens();
            //end of added line
        }
//added method
private static void ConfigureAntiForgeryTokens()
{
    AntiForgeryConfig.CookieName = "custom_name";

    // AntiForgeryConfig.RequireSsl = true;
}
//end of added method
```
If your site will use Ssl, uncomment the last line.
###### Renaming the Application cookie
This is done in the Startup.Auth.cs file of the App_Start folder
```aspnet
public void ConfigureAuth(IAppBuilder app)
{
    app.UseCookieAuthentication(new CookieAuthenticationOptions
    {
        AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
        LoginPath = new PathString("/Account/Login"),
        CookieName = "custom_name"
    });
}
```
#### 8. Disable tracing
```XML
<system.web>
  <trace enabled="true" localOnly="true"/>
</system.web>
```

#### 9. Display 403 - Forbidden response as a 404
When you navigate to a directory in IIS and ASP.NET MVC, it causes a 403 - Forbidden response to be returned. This basically means that directory browsing is disabled. Directory browsing is a security risk, as it grants access to the web.config file with all your connection strings.
When directory browsing returns a 403, it poses a problem as it tells a potential attacker that you're using IIS and there actually is a folder there.
We fix this by replacing the 403 response with the standard 404.

First we add httpErrors to the web.config file.
```XML
<system.webServer>
  <!-- Custom error pages -->
  <httpErrors errorMode="Custom" existingResponse="Replace">
    <!-- Redirect IIS 403 Forbidden responses to the not found action method on error controller -->
    <error statusCode="403" subStatusCode="14" responseMode="ExecuteURL" path="/error/notfound" />
  </httpErrors>
</system.webServer>
```
Then we turn off IIS' default document handling. This stops IIS from returning the default document (Using whats called a courtesy redirect) when navigating to a folder e.g. navigating to â€˜/Folder’ which contains an index.html file will not return â€˜/Folder/index.html’. If it redirects to the default document, in the page url, it displays the directory's path to potential attackers and we wouldn't want that.

```XML
<system.webServer>
  <defaultDocument enabled="false"/>
</system.webServer>
```

Using the few tips above, you can make your ASP.NET Application more secure.ðŸ˜ Thanks for reading! ðŸ˜„ðŸ™‚