Overview

Content Security Policy (CSP) is a security feature that helps prevent a variety of attacks such as Cross-Site Scripting (XSS) and data injection attacks. By defining a CSP, developers can control which resources the browser is allowed to load for a given page. This minimizes the risk of malicious scripts being executed, thereby protecting sensitive data and maintaining the integrity of the application.

The primary problem CSP addresses is the exploitation of vulnerabilities where attackers inject malicious scripts into web pages. For instance, if an attacker manages to inject a script that sends user data to their server, a properly configured CSP can block that script from running. Real-world use cases include protecting online banking applications, e-commerce platforms, and any web application that handles sensitive user data.

Prerequisites

• ASP.NET Core MVC: Basic knowledge of building web applications using ASP.NET Core MVC framework.
• Middleware Concepts: Understanding how middleware works in ASP.NET Core and how it can be used to manipulate HTTP requests and responses.
• Basic Web Security: Familiarity with web security concepts like XSS, CSRF, and the importance of securing web applications.

Understanding Content Security Policy (CSP)

Content Security Policy provides a way for web developers to control resources the user agent is allowed to load. It operates through HTTP headers or HTML meta tags. The most common directive is script-src, which defines valid sources for JavaScript. By specifying where scripts can be loaded from, developers can prevent unwanted scripts from being executed.

Another important directive is default-src, which serves as a fallback for other directives if they are not explicitly defined. CSP can also be tailored to allow inline scripts or styles through the use of the unsafe-inline keyword, but this is generally discouraged due to security implications. Therefore, using nonces or hashes for inline scripts is recommended to maintain a higher level of security.

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    app.UseCsp(options => options
        .DefaultSources(s => s.Self())
        .ScriptSources(s => s.Self().CustomSources("https://trustedscripts.example.com"))
        .StyleSources(s => s.Self().UnsafeInline())
    );
    // Other middleware setups...
}

This code configures the CSP middleware in an ASP.NET Core application. The UseCsp method is called to set up the policy. The DefaultSources directive specifies that only resources from the same origin are allowed. The ScriptSources directive allows scripts to be loaded from the same origin and an additional trusted source. The StyleSources directive restricts styles to the same origin and permits inline styles, which could be a potential security risk.

Defining CSP Directives

Defining CSP directives allows for granular control over resource loading. Each directive can be tailored to specific needs. For example, you can define where images can come from using img-src or where fonts can be loaded using font-src.

app.UseCsp(options => options
    .ImgSources(s => s.Self().CustomSources("https://images.example.com"))
    .FontSources(s => s.Self().CustomSources("https://fonts.example.com"))
);

In this example, the ImgSources directive restricts image loading to the same origin and a specific image source. The FontSources directive does the same for fonts. This level of detail helps tighten security by minimizing the attack surface.

Implementing CSP Middleware in ASP.NET Core

To implement CSP in an ASP.NET Core application, you can use existing middleware packages or create your own middleware. Using a package simplifies the process as it abstracts away some complexities. The NWebsec package is a popular choice for implementing CSP in ASP.NET Core applications.

public void ConfigureServices(IServiceCollection services)
{
    services.AddCsp(options => options
        .DefaultSources(s => s.Self())
        .ScriptSources(s => s.Self().CustomSources("https://trustedscripts.example.com"))
    );
}

In this example, the AddCsp method is called in the ConfigureServices method of the startup class. This sets up the CSP options, specifying default sources and script sources. Once configured, the middleware will automatically add the appropriate headers to HTTP responses.

Custom Middleware for CSP

While using established libraries is recommended, creating custom middleware allows for greater flexibility. Custom middleware can be tailored to specific requirements and can perform additional logic before sending headers.

public class CspMiddleware
{
    private readonly RequestDelegate _next;

    public CspMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task Invoke(HttpContext context)
    {
        context.Response.Headers.Add("Content-Security-Policy", "default-src 'self'; script-src 'self' https://trustedscripts.example.com;");
        await _next(context);
    }
}

This custom middleware adds a CSP header directly to the response. You can modify the policy string to fit your security requirements. The Invoke method processes the request, adds the CSP header, and then calls the next middleware in the pipeline.

Edge Cases & Gotchas

When implementing CSP, developers should be aware of common pitfalls. One common mistake is overly restrictive policies that break functionality. For example, blocking all inline scripts may prevent legitimate scripts from running if they are not handled correctly.

// Too restrictive CSP example
app.UseCsp(options => options
    .DefaultSources(s => s.None())
    .ScriptSources(s => s.None())
);

The above code will block all resources from loading, resulting in a non-functional application. Instead, a balanced approach should be taken, allowing necessary resources while still maintaining security.

Using Nonces and Hashes

To allow inline scripts while maintaining a secure policy, using nonces or hashes is advisable. A nonce is a random value that must be included in the script tag in the HTML, while hashes are calculated from the script content.

context.Response.Headers.Add("Content-Security-Policy", "script-src 'self' 'nonce-randomvalue';");

In this snippet, a nonce is added to allow a specific inline script. This approach is secure as only scripts with the matching nonce will be executed. Ensure to generate a unique nonce for each request to maintain security.

Performance & Best Practices

Performance can be affected by CSP, especially when using complex policies or allowing many external resources. Regularly review and refine your CSP to remove unnecessary directives and sources. This reduces overhead and improves load times.

// Example of a refined CSP
app.UseCsp(options => options
    .DefaultSources(s => s.Self())
    .ScriptSources(s => s.Self().CustomSources("https://trustedscripts.example.com"))
    .StyleSources(s => s.Self());

This refined policy focuses on essential sources only, improving performance. Additionally, testing CSP with tools like Google Chrome's CSP Evaluator can help identify potential issues and enhance policies.

Monitoring and Reporting CSP Violations

Monitoring and reporting CSP violations is essential for maintaining security. By adding a report-uri directive, you can collect violations for analysis.

app.UseCsp(options => options
    .ReportUris(s => s.CustomSources("https://your-report-collector.example.com"))
);

This code configures the middleware to send reports of CSP violations to a specified URL. This allows developers to monitor potential security breaches and adjust their policies accordingly.

Real-World Scenario: Mini-Project

Imagine a simple ASP.NET Core MVC application that displays user data and allows image uploads. In this scenario, implementing CSP is critical to protect user information and prevent XSS attacks.

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddControllersWithViews();
        services.AddCsp(options => options
            .DefaultSources(s => s.Self())
            .ScriptSources(s => s.Self().CustomSources("https://trustedscripts.example.com"))
            .ImgSources(s => s.Self().CustomSources("https://images.example.com"))
        );
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        app.UseCsp(options => options
            .ReportUris(s => s.CustomSources("https://your-report-collector.example.com"))
        );
        app.UseRouting();
        app.UseEndpoints(endpoints =>
        {
            endpoints.MapControllerRoute(
                name: "default",
                pattern: "{controller=Home}/{action=Index}/{id?}
            );
        });
    }
}

This complete ASP.NET Core MVC application example implements CSP with safe defaults. It allows images from a trusted source and scripts from the same origin and a specified external source. The reporting feature is included to monitor violations.

Conclusion

• Content Security Policy is vital for securing web applications against various attacks.
• Implementing CSP in ASP.NET Core MVC enhances security by controlling resource loading.
• Utilizing middleware and libraries like NWebsec simplifies CSP implementation.
• Regularly review and refine your CSP policies for optimal performance and security.
• Monitoring CSP violations helps identify vulnerabilities and improve security posture.

Next, consider learning about other security headers like X-Content-Type-Options and Strict-Transport-Security to further enhance your application's security.