Unicode Normalization in Aspnet with Dynamodb

Unicode normalization inconsistencies between ASP.NET model binding and Amazon DynamoDB key handling can lead to authentication bypass, IDOR, and data exposure. In ASP.NET, incoming request data (form values, route tokens, query strings) is bound to action parameters using default model binders that do not enforce a canonical normalization form. Developers often compare user-supplied identifiers directly with values retrieved from DynamoDB, where primary key attribute values may be stored in a different Unicode composition (e.g., NFC vs NFD). This mismatch enables equivocation attacks: an attacker can supply a visually and semantically equivalent string that normalizes to the same logical identifier but hashes or compares differently at the application layer versus the database layer.

Consider an ASP.NET Core API that uses a string userId as a DynamoDB partition key. If the client sends café (U+00E9, composed) and the stored item uses café (U+0065 + U+0301, decomposed), the in-memory model binder may leave the string as supplied, while a direct low-level lookup against the DynamoDB key may treat them as distinct because the service stores the exact byte sequence provided at write time. This discrepancy can allow an authenticated user to manipulate the URL or JSON payload to reference another user’s resource by supplying a normalization-variant identifier that bypasses intended access checks.

In practice, this surfaces in endpoints that accept user-controlled identifiers without normalization before constructing DynamoDB requests. For example, an endpoint like /api/users/{userId} might call GetItem on DynamoDB using the raw route value, while the stored item’s partition key was normalized differently during registration or import. Because the scan category BOLA/IDOR tests whether authorization checks are applied consistently across the request path and the data store, such normalization gaps are flagged as high-severity findings that can enable horizontal or vertical privilege escalation.

Additionally, query parameters and JSON payload fields that are used as DynamoDB filter expressions or key condition expressions can introduce further risk if normalization is not applied consistently. An attacker may submit parameters that exploit canonical equivalence to evade pattern-based validation, reach sensitive records, or cause inconsistent logging and monitoring behavior. The LLM/AI Security checks do not directly test Unicode normalization, but the broader scan includes input validation and property authorization checks that highlight these inconsistencies when combined with DynamoDB’s exact-match key semantics.

To mitigate, normalize all user-controlled identifiers to a canonical form (typically NFC) in ASP.NET before using them in DynamoDB requests, and ensure the same normalization is applied when storing and retrieving items. This aligns in-memory representations with the data stored in the database, closing the equivalence vector that would otherwise allow bypass of access controls.

Apply Unicode normalization at the boundary where ASP.NET receives identifiers and before constructing DynamoDB requests. Use the System.Text.Normalization APIs to convert strings to NFC, and ensure this normalization is applied consistently for reads, writes, and comparisons. Below are concrete examples for an ASP.NET Core API that uses Amazon DynamoDB via the AWS SDK for .NET.

Normalization helper

using System.Text;

public static class UnicodeNormalization
{
    public static string Normalize(string input)
    {
        if (string.IsNullOrEmpty(input))
        {
            return input;
        }
        // Use FormC to ensure canonical composition
        return input.Normalize(NormalizationForm.FormC);
    }
}

ASP.NET Core controller with normalized DynamoDB access

using Amazon.DynamoDBv2;
using Amazon.DynamoDBv2.Model;
using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/users")]
public class UsersController : ControllerBase
{
    private readonly IAmazonDynamoDB _dynamoDb;

    public UsersController(IAmazonDynamoDB dynamoDb)
    {
        _dynamoDb = dynamoDb;
    }

    [HttpGet("{userId}")]
    public async Task<IActionResult>GetUser(string userId)
    {
        var normalizedUserId = UnicodeNormalization.Normalize(userId);

        var request = new GetItemRequest
        {
            TableName = "Users",
            Key = new Dictionary<string, AttributeValue>
            {
                ["PK"] = new AttributeValue { S = normalizedUserId }
            }
        };

        var response = await _dynamoDb.GetItemAsync(request);

        if (response.Item == null || !response.Item.TryGetValue("Profile", out var profileAttr))
        {
            return NotFound();
        }

        return Ok(new { UserId = normalizedUserId, Profile = profileAttr.S });
    }

    [HttpPost]
    public async Task<IActionResult>CreateUser([FromBody] UserInput input)
    {
        var normalizedUserId = UnicodeNormalization.Normalize(input.UserId);

        var putRequest = new PutItemRequest
        {
            TableName = "Users",
            Item = new Dictionary<string, AttributeValue>
            {
                ["PK"] = new AttributeValue { S = normalizedUserId },
                ["Email"] = new AttributeValue { S = input.Email }
            }
        };

        await _dynamoDb.PutItemAsync(putRequest);

        return CreatedAtAction(nameof(GetUser), new { userId = normalizedUserId }, null);
    }
}

public class UserInput
{
    public string UserId { get; set; }
    public string Email { get; set; }
}

Normalizing in low-level DynamoDB calls

If you use the low-level client or document layer abstractions, apply normalization before forming keys or expressions:

var normalizedPartitionKey = UnicodeNormalization.Normalize(userId);
var request = new GetItemRequest
{
    TableName = "UserProfiles",
    Key = new Dictionary<string, AttributeValue>
    {
        ["PK"] = new AttributeValue { S = normalizedPartitionKey },
        ["SK"] = new AttributeValue { S = "PROFILE" }
    }
};
var response = await _dynamoDb.GetItemAsync(request);

Validation with normalization

Combine normalization with whitelist or length checks to reduce risk further. For identifiers that must adhere to a specific pattern, normalize first, then validate:

public static bool IsValidUserId(string userId)
{
    var normalized = UnicodeNormalization.Normalize(userId);
    // Allow alphanumeric plus underscore, 3..64 chars
    return System.Text.RegularExpressions.Regex.IsMatch(normalized, @"^[\w]{3,64}$");
}

Middleware approach

For broader protection in ASP.NET Core, implement a normalization step in model binding or an action filter so that all incoming identifiers are canonicalized before reaching handlers:

using Microsoft.AspNetCore.Mvc.Filters;

public class NormalizeRouteValueAttribute : ActionFilterAttribute
{
    public override void OnActionExecuting(ActionExecutingContext context)
    {
        if (context.RouteData.Values.TryGetValue("userId", out var value) && value is string userId)
        {
            context.RouteData.Values["userId"] = UnicodeNormalization.Normalize(userId);
        }
    }
}

By consistently normalizing at the entry point and persisting normalized keys in DynamoDB, you eliminate equivalence-based bypasses across the stack and reduce findings related to BOLA/IDOR and input validation in scans.