Auth Bypass in Aspnet with Redis

An authentication bypass in an ASP.NET application that uses Redis typically occurs when session or token data is stored in Redis without sufficient integrity checks and the application trusts that data to make authorization decisions. For example, if you store a claims principal or a serialized authentication ticket in Redis and later reconstruct it on the server based only on the presence of a key, an attacker who can influence the key or tamper with the stored value may be able to forge a valid session.

Consider a common pattern: on login, the server writes a Redis hash like session:{sessionId} containing user ID, roles, and an expiration timestamp, then returns the session ID to the client in a cookie. If the session ID is predictable, leaked via a referrer, or exposed in logs, an attacker can copy a valid session ID and present it to Redis. Even if the cookie is marked HttpOnly, if the application does not re-validate the binding between the session ID and the current user context on each request, Redis simply returns the stored data and the app treats it as trusted.

More critically, ASP.NET’s distributed caching and session providers for Redis rely on consistent serialization and deserialization. If the application deserializes data from Redis using a less-restrictive format or custom logic that does not validate types and claims, an attacker who can control the stored payload (for instance, via a secondary injection flaw or through insecure admin interfaces that write to Redis) may inject malicious claims such as role: admin. Upon deserialization, the reconstructed principal will contain those claims, and policy-based authorization checks that rely on User.IsInRole("admin") will incorrectly grant elevated privileges.

Insecure configuration can exacerbate the issue. If Redis is exposed without network ACLs or TLS, an attacker on the network can read or modify session keys. Additionally, if your ASP.NET app uses a shared Redis instance across services and does not namespace keys carefully, cross-service leakage may allow one compromised service to influence another’s session store. The lack of server-side per-request re-verification against a trusted source of truth means Redis-stored session data effectively becomes the authority, and any weakness in how that data is written, read, or serialized becomes an auth bypass vector.

Real-world attack patterns mirror OWASP API Top 10 authentication and authorization flaws, where broken object level authorization (BOLA) intersects with insecure storage. For instance, an attacker might iterate over predictable session IDs (enumeration) to locate valid keys in Redis, then craft requests with those IDs to bypass intended access controls. This is not a theoretical risk; similar vectors have been observed in the wild where session stores were directly reachable and lacked proper validation.

To mitigate auth bypass when using Redis in ASP.NET, enforce strict separation and validation of authentication data, and avoid trusting data stored in Redis without re-verification. The following patterns demonstrate secure handling of Redis in authentication flows.

Secure session storage with signature verification

Instead of storing the full principal in Redis, store a minimal, server-side session record keyed by a cryptographically random session ID. Keep the authoritative user data in your database and always re-fetch it on each request. Use a signed cookie to bind the session ID to the client.

// Generate a secure random session identifier
var sessionId = Convert.ToBase64String(RandomNumberGenerator.GetBytes(32));
var redisKey = $"session:{sessionId}";

// Store minimal, non-trusted metadata in Redis with an explicit expiration
var sessionData = new { UserId = user.Id, CreatedAt = DateTime.UtcNow };
await database.StringSetAsync(redisKey, JsonSerializer.Serialize(sessionData), TimeSpan.FromMinutes(30));

// Set a signed cookie containing only the session ID
var cookieOptions = new CookieOptions
{
    HttpOnly = true,
    Secure = true,
    SameSite = SameSiteMode.Strict,
    Expires = DateTime.UtcNow.AddMinutes(30)
};
Response.Cookies.Append("session_id", sessionId, cookieOptions);

On each request, read the session ID from the cookie, fetch the data from Redis, and re-validate against the database instead of relying on the deserialized principal.

// In middleware or an action filter
var sessionId = Request.Cookies["session_id"];
if (string.IsNullOrEmpty(sessionId))
{
    context.Result = Challenge();
    return;
}

var redisKey = $"session:{sessionId}";
var cached = await database.StringGetAsync(redisKey);
if (!cached.HasValue)
{
    context.Result = Challenge();
    return;
}

var session = JsonSerializer.Deserialize<SessionData>(cached);
if (session == null || session.CreatedAt < DateTime.UtcNow.AddMinutes(-30))
{
    context.Result = Challenge();
    return;
}

// Re-fetch the current user from the trusted data store
var user = await userRepository.GetByIdAsync(session.UserId);
if (user == null)
{
    context.Result = Challenge();
    return;
}

// Build a fresh principal for this request based on current data
var identity = new ClaimsIdentity(new[]
{
    new Claim(ClaimTypes.NameIdentifier, user.Id.ToString()),
    new Claim(ClaimTypes.Name, user.UserName)
}, Scheme.Name);
context.User = new ClaimsPrincipal(identity);

Avoiding insecure deserialization when using IDistributedCache

If you use ASP.NET’s IDistributedCache (which can be backed by Redis), do not store sensitive authorization decisions in cache entries that are later used for policy evaluation without re-validation. Prefer storing only identifiers and rehydrating user data from a trusted source.

// Do not do this: caching a ClaimsPrincipal directly
// await _distributedCache.SetAsync("principal_key", SerializePrincipal(principal), ...);

// Instead, cache only identifiers and reconstruct safely
var userIdClaim = User.FindFirst(ClaimTypes.NameIdentifier);
if (userIdClaim != null)
{
    var userId = userIdClaim.Value;
    await _distributedCache.SetStringAsync($"lastrequest:{userId}", DateTime.UtcNow.ToString("o"), new DistributedCacheEntryOptions
    {
        AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(5)
    });
    // Re-fetch user and roles on each request; do not trust cached principal
}

Key hardening measures

• Use strong random session IDs and keep them in HttpOnly, Secure, SameSite cookies.
• Namespace Redis keys explicitly (e.g., session:{id}, authz:{userId}) to avoid cross-service leakage.
• Enable TLS for Redis connections and restrict network access with firewall rules.
• Never store roles or permissions directly in Redis as trusted data; always re-validate against the primary data store.
• Monitor and rotate Redis credentials and review access patterns to detect anomalous key access.