Skip to main content

Cached form fields

Need​

Prevention of sensitive data exposure through cached form fields

Context​

  • Usage of C# 8.0 for modern and efficient software development
  • Usage of Microsoft.AspNetCore for building web applications with .NET Core
  • Usage of Microsoft.AspNetCore.Hosting for hosting ASP.NET Core applications
  • Usage of Microsoft.AspNetCore.Builder for configuring and building ASP.NET Core applications
  • Usage of Microsoft.AspNetCore.Http for handling HTTP requests and responses in ASP.NET Core applications
  • Usage of Microsoft.Extensions.Hosting for building and hosting .NET applications
  • Usage of Microsoft.Extensions.DependencyInjection for dependency injection in .NET applications
  • Usage of Microsoft.Extensions.Configuration for managing configuration settings in a .NET application

Description​

Non compliant code​

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Home/Error");
        app.UseHsts();
    }

    app.UseHttpsRedirection();
    app.UseStaticFiles();

    app.UseRouting();

    app.UseAuthorization();

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

The above code is a typical configuration for an ASP.NET Core application. It sets up various middleware components for handling HTTP requests.

However, this code does not include any measures to prevent caching of form fields. This means that if a user fills out a form in the application, the data they enter could be stored in the browser's cache. This could potentially expose sensitive data to anyone who has access to the user's browser.

The vulnerability lies in the fact that the application does not instruct the browser not to cache sensitive data. This could be a problem if, for example, the form is used to collect payment information or other sensitive data.

In the code, there is no use of app.UseResponseCaching() or any other middleware that could prevent caching on the client side. Even though the application might use HTTPS for secure transmission of data, the data could still be cached on the client side if the application does not take measures to prevent this.

The lack of caching prevention could lead to a potential data leak on the client side, which might be exploited by an attacker with access to the client's browser.

Steps​

  • Disable caching of input fields in the application
  • Set appropriate cache-control headers to prevent caching of sensitive data
  • Implement anti-csrf measures to protect against form tampering

Compliant code​

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Home/Error");
        app.UseHsts();
    }

    app.UseHttpsRedirection();
    app.UseStaticFiles();

    app.UseRouting();

    app.UseAuthorization();

    app.Use((context, next) =>
    {
        context.Response.GetTypedHeaders().CacheControl = new CacheControlHeaderValue()
        {
            NoStore = true,
            NoCache = true,
            MustRevalidate = true,
            Private = true
        };
        context.Response.Headers[HeaderNames.Pragma] = "no-cache";
        return next();
    });

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

The above code fixes the vulnerability by setting appropriate cache-control headers to prevent caching of sensitive data.

The app.Use middleware is used to set the CacheControl header of the response. The NoStore option is set to true to prevent the browser and all intermediate caches from storing any version of the returned response. The NoCache option is also set to true to indicate that the returned response can't be used to satisfy a subsequent request to the same URL without first checking with the server if the response has changed. The MustRevalidate option is set to true to indicate that once the resource becomes stale, caches must not use their stale copy without successful validation on the origin server. The Private option is set to true to indicate that the response message is intended for a single user and must not be cached by a shared cache.

The Pragma header is also set to no-cache to include older HTTP 1.0 caches that do not understand the Cache-Control header.

This way, the application ensures that sensitive data from form fields is not cached, thus mitigating the risk of information leakage.

References​

Last updated on