How to secure your .NET Core Web Application with NWebSec

Image source: iStockphoto

Nowadays, web attackers have so many ways as well as tools to attack your web site. Go along with this; web development frameworks (i.e. .NET Framework, .NET Core…) also release new features, plugins and libraries which support your application can stay safe in attacks from the hacker. All you need is that choosing the right library, right feature for your application.

There are many things to consider when securing a web application but a definite “quick win” is to start taking advantage of the security HTTP response headers that are supported in most of the modern browser.

Security headers in an HTTP Response (source: dotnetnoob.com)

In this article, I’m not intending to explain to you “What are secure HTTP response headers?” because you can find everything which you need in this article — I still visit it regularly when I need to explain to someone about security HTTP response headers. I will only focus on applying NWebSec library to .NET Core Application.

First thing first, let’s install NWebSec middleware from Nuget via the package manager.

So, what secure HTTP response headers can do?
- Protecting web resources, only securely authorised can access these resources.
- Making it as hard as possible for potential attackers to glean information from your web site.

Let’s walk through security headers that are supported by major browsers — the list which I list down as below might not exhaustive:

1. [HSTS] HTTP Strict Transport Security Header
2. X-XSS-Protection Header
3. X-Frame-Options Header
4. [CSP] Content-Security-Policy Header
5. X-Content-Type-Options Header
6. Referrer-Policy HTTP Header
7. Remove the X-Powered-By Header (in order to remove the additional information transferred by verifying the app tech)

[HSTS] HTTP Strict Transport Security Header

All communications have to go through HTTPS!

.Preload() method indicated below forces it from the first request.

NOTE: I only use HTTPS for Staging and Production environment.

X-XSS-Protection Header

This prevents pages from loading in modern browsers when reflected cross-site scripting is detected. This is often unnecessary if a site implements a strong Content-Security-Policy.

X-Frame-Options Header

This header ensures that site content is not being embedded in an iframe on other sites- used to avoid clickjacking attacks.

[CSP] Content-Security-Policy Header

If you want nobody can access your home (obviously except your family) and steal your properties then you should lock all the doors and share the key with your family.

Basically, the Content-Security-Policy header allows you to whitelist resource origins when the site is loaded.

There are a lot of different ways you can configure this and they are much dependent upon your specific requirement.

Here is an example:

X-Content-Type-Options Header

Attackers are very smart. They can change an innocent MIME type (e.g. text/css) into something that could be executable. This could make some real damage.

Referrer-Policy Http Reader

This header tells the site how much information to send along in the Referrer header field.

Remove X-Powered-By Header

Finally, we should make sure that any information regarding web server, technology in use (i.e. ASP.NET, Kestrel) is not passed to web client. To do this, we’ll remove the X-Powered-By header by adding to web.config.

NOTE: With ASP.NET Core we can update AddServerHeader option of .UseKestrel to false (true by default)

Reference links:

OWASP

NWebsec - Security libraries for ASP.NET Core - NWebsec documentation