Need

Implementation of secure and properly configured Content-Security-Policy headers

Context

• Usage of C# 7.0 for modern language features and enhancements
• Usage of Microsoft.AspNetCore.Builder for configuring the ASP.NET Core application pipeline
• Usage of Microsoft.AspNetCore.Hosting for hosting ASP.NET Core applications
• Usage of Microsoft.AspNetCore.Http for handling HTTP requests and responses in ASP.NET Core applications
• Usage of Microsoft.AspNetCore.Mvc for building web applications with ASP.NET Core
• Usage of Microsoft.Extensions.Hosting for building and hosting .NET Core applications

Description

Non compliant code

        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Home/Error");
        // The host app doesn't add the Content Security Policy (CSP) header.
    }

    app.UseStaticFiles();

    app.UseRouting();

    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllerRoute(
            name: "default",
            pattern: "{controller=Home}/{action=Index}/{id?}");
    });
}
        
        

In the above code, the ASP.NET Core application is configured to use various middleware in the Configure method. However, there is no middleware configured to add the Content-Security-Policy HTTP header to the responses.

The Content-Security-Policy is an important security header that can help to prevent a range of attacks, including Cross-site Scripting (XSS) and data injection attacks. By not including this header, the application is leaving itself open to these types of attacks.

Moreover, even if the Content-Security-Policy header was added, it is also important to ensure that the defined security policies do not contain insecure values. For example, a policy of 'unsafe-inline' or 'unsafe-eval' can expose the application to potential XSS attacks.

As such, the absence of the Content-Security-Policy header or the presence of insecure values in this header represents a significant security vulnerability in the application.

Steps

• Add the Content-Security-Policy header to the server responses.
• Define the mandatory security policies in the Content-Security-Policy header.
• Ensure that the defined security policies do not contain insecure values.

Compliant code

        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Home/Error");
        // The host app now adds the Content Security Policy (CSP) header.
        app.Use(async (context, next) =>
        {
            context.Response.Headers.Add("Content-Security-Policy", "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self'; connect-src 'self';");
            await next();
        });
    }

    app.UseStaticFiles();

    app.UseRouting();

    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapControllerRoute(
            name: "default",
            pattern: "{controller=Home}/{action=Index}/{id?}");
    });
}
        
        

The above code fixes the vulnerability by adding the Content-Security-Policy (CSP) header to the server responses. This is done in the else block of the Configure method, where we add a middleware using the Use method of the IApplicationBuilder instance.

The middleware is an asynchronous function that takes the HTTP context and the next middleware in the pipeline as parameters. Inside this function, we add the CSP header to the response headers of the context. The CSP header is set to allow resources only from the same origin ('self').

This policy is a strong one, as it only allows resources to be loaded from the same origin. This means that all scripts, styles, images, and connections must be from the same origin. This policy can be adjusted according to the needs of the application.

After adding the header, the middleware calls the next middleware in the pipeline using the await next(); statement.

This fix ensures that the CSP header is present in all server responses, and that it has a strong policy that does not contain insecure values. This helps to mitigate the risk of content injection attacks.

References

• 043. Insecure or unset HTTP headers - Content-Security-Policy