Skip to main content

Enabled default configuration

Need

Disable default configurations to prevent unauthorized access and information disclosure

Context

  • Usage of C# 7.0 for modern language features and enhancements
  • Usage of Microsoft.AspNetCore.Mvc for building web applications with ASP.NET Core
  • Usage of Microsoft.AspNetCore.StaticFiles for serving static files in ASP.NET Core applications
  • Usage of Microsoft.Extensions.DependencyInjection for dependency injection in .NET applications
  • Usage of Microsoft.Extensions.Hosting for building and hosting .NET Core applications
  • Usage of Microsoft.Extensions.Hosting.Abstractions for abstracting the hosting of .NET applications

Description

Non compliant code

public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
}

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

app.UseStaticFiles();

app.UseRouting();

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

The above code is a typical startup configuration for an ASP.NET Core application. The vulnerability in this code lies in the default route configuration in the Configure method.

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

The above code sets up a default route where if no controller and action are specified in the URL, it defaults to the Home controller and the Index action. This is the server's default page. If this page contains technical information about the server, it can be accessed by an attacker.

For example, if the Home controller's Index action returns a view that includes server details, an attacker could access these details simply by navigating to the base URL of your application.

This could provide an attacker with valuable information about your server, such as its operating system, the versions of software it's running, and other details that could help them plan an attack.

Steps

  • Disable the default page in the server configuration.
  • Remove or customize the default error handling page.
  • Ensure that sensitive server information is not exposed in error messages or responses.

Compliant code

public class Startup
{
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc();
}

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
else
{
// Custom error handling page
app.UseExceptionHandler("/CustomErrorPage");
}

app.UseStaticFiles();

app.UseRouting();

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

The above code fixes the vulnerability by disabling the default page and error handling page in the server configuration.

In the Configure method, the UseExceptionHandler method is updated to use a custom error handling page instead of the default one. This is done to prevent exposure of sensitive server information in error messages or responses.

The UseEndpoints method is also updated to use a custom route instead of the default one. This is done to prevent unauthorized access to the server's default page.

Remember to create the custom error handling page and the custom controller with its corresponding action method to handle the requests.

This way, we ensure that the server's default page is not enabled and that relevant technical information about the server is not exposed, thus fixing the vulnerability.

References