JWT Header Injections & Algoritm Confusion attacks

The JWT format token is usually generated as follows: After the client transmits its credentials to the server and validates them, the server generates a JWT token. The JWT token is generated by the server using the following values: 1. HEADER, which contains information pertaining to the server-side JWT configuration (such as the employed algorithm for signature generation/validation, the identifier of the key for utilization (???)). 2. PAYLOAD, generated by the server according to a template based on preset informational values, as well as static and session information about the client (e.g. user ID, token update data, token representative resource, token usage context) 3. SIGNATURE, serving as the "seal" of the token. SIGNATURE is an encapsulation of a hash value of the concatenation of HEADER and PAYLOAD, encrypted with a key or key pair, as defined by the chosen encryption scheme.

Usually, JWT refresh token is also generated. Upon the subsequent presentation of the provided token by the client, it's validated by server via the repetition of signature generation and its comparison with the presented signature.

Attacks of the "algorithm confusion" type are reliant on the assumption that, during JWT validation, instead of mandatorily sticking to predefined algorithms, the server will fall back to an algorithm specified within the received token. For instance, attacks on systems implementing asymmetric encryption algorithms, such as RS256, can, in theory, contain a misconfiguration, where, after reading the alg value in the HEADER of the token, the server proceeds to validate it by utilizing a public key as a shared secret, instead of using it's private key for that. A similar vulnerability may arise if a "none" algorithm is specified. Furthermore, the injection of jwk and jku headers within the scope of user authentication by a vulnerable server will result in the server employing keys or their sources, as contained in supplied tocken's HEADER, for it's validation.

A mitigation strategy for such attacks should consist of the establishment and utilization of a static signature validation algorithm or a list of expected algorithms. If a list is chosen - avoid mixing asymmetric algorithms with HS.

//// Program.cs
// ...
builder.Services.AddAuthentication(x =>
    {
    x.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
    x.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
    x.DefaultScheme = JwtBearerDefaults.AuthenticationScheme;
    }).AddJwtBearer(x =>
      {
      x.TokenValidationParameters = new Microsoft.IdentityModel.Tokens.TokenValidationParameters
      {
      // grabbing Issuer and Audience from appsettings.json
      ValidIssuer = config["JwtSettings:Issuer"],
      ValidAudience = config["JwtSettings:Audience"],
      // safely grabbing JWT_SECRET_KEY from an environment. This can be provided to a container via a, 
      // for example, CD-pipeline-side K8s Pod object that is referencing a SealedSecret
      IssuerSigningKey = new Microsoft.IdentityModel.Tokens.SymmetricSecurityKey(
              System.Text.Encoding.UTF8.GetBytes(Environment.GetEnvironmentVariable("JWT_SECRET_KEY"))
              ),
      // requiring algorithm usage, this prevents algorithm confusion attacks, if set properly
      ValidAlgorithms = new[] {"HS256"},
      // setting validation policies
      ValidateIssuer = true,
      ValidateAudience = true,
      ValidateLifetime = true,
      // this prevents arbitrary signature validation
      ValidateIssuerSigningKey = true
      };
      });
// ...