Security controls bypass or absence - Session Invalidation - C-Sharp

Security controls bypass or absence - Session Invalidation - C-Sharp

Need

Implementation of proper session invalidation mechanism

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 MVC
  • Usage of Microsoft.AspNetCore.Http for handling HTTP requests and responses in ASP.NET Core applications
  • Usage of Microsoft.AspNetCore.Session for managing user sessions in ASP.NET Core

Description

Non compliant code

        public class UserController : Controller
{
    private readonly IHttpContextAccessor _httpContextAccessor;
    private ISession _session => _httpContextAccessor.HttpContext.Session;
    
    public UserController(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }
    
    public IActionResult Main()
    {
        var sessionCode = _session.GetString("SessionCode");
        
        if (sessionCode == "auto")
        {
            return View("Main");
        }
        else
        {
            return View("Error");
        }
    }
}
        
        

In the above code, the UserController class has a method Main which checks the session code of the user. If the session code is "auto", the user is redirected to the "Main" view, otherwise, the user is redirected to the "Error" view.

The IHttpContextAccessor interface is used to access the HTTP context. The _session property is used to get the current session from the HTTP context.

The vulnerability here is that the session code "auto" is hard-coded into the Main method. This means that if a user knows this session code, they can bypass the usual security checks and gain access to the "Main" view. This is a security risk as it allows unauthorized access to the application.

This vulnerability occurred because the source code used in the debugging phase was left in this functionality. During the debugging phase, it's common to use hard-coded values to test the functionality of the code. However, these hard-coded values should be removed before the code is deployed to prevent security vulnerabilities.

Steps

  • Remove the debugging code that allows access with session code containing the word 'auto'.
  • Implement a proper session invalidation mechanism.
  • Ensure that the session code is securely generated and cannot be easily guessed or manipulated.

Compliant code

        public class UserController : Controller
{
    private readonly IHttpContextAccessor _httpContextAccessor;
    private ISession _session => _httpContextAccessor.HttpContext.Session;
    
    public UserController(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }
    
    public IActionResult Main()
    {
        var sessionCode = _session.GetString("SessionCode");
        
        // Removed the debugging code that allows access with session code containing the word 'auto'.
        if (string.IsNullOrEmpty(sessionCode) || sessionCode != "secureSessionCode")
        {
            return View("Error");
        }
        else
        {
            return View("Main");
        }
    }
}
        
        

The original code had a vulnerability where a session code containing the word 'auto' would allow access to the main view. This was a leftover from the debugging phase and posed a security risk as it bypassed the normal security controls.

The fixed code removes this debugging backdoor. Now, the session code is checked to ensure it is not null or empty and matches a secure session code. If these conditions are not met, the user is redirected to an error page. This ensures that the session code is securely generated and cannot be easily guessed or manipulated.

In addition, a proper session invalidation mechanism should be implemented to further enhance the security of the application. This could involve setting a timeout for the session or invalidating the session after a certain number of failed login attempts. This would prevent an attacker from being able to use a stolen or guessed session code to gain unauthorized access to the application.

References