Prototype Pollution in Aspnet with Dynamodb

Prototype pollution in the context of an ASP.NET application interacting with Amazon DynamoDB typically arises when user-controlled input is merged into server-side objects that are later serialized or used to construct DynamoDB attribute values. In JavaScript-like environments (e.g., Node.js services called from ASP.NET or Blazor WebAssembly), prototype pollution can let an attacker add or modify properties on Object.prototype, affecting behavior across the runtime. When the polluted object is translated into a DynamoDB Document or passed through model binders into parameters used with the AWS SDK for .NET, unexpected attributes can be written to the item.

For example, an ASP.NET Core controller might accept JSON that is deserialized into a Dictionary or a dynamic entity before being passed to PutItemRequest. If the input includes keys like __proto__, constructor, or prototype, and the server-side code does not sanitize these keys, the pollution can manifest in two ways:

• Logic pollution: When the item is later reconstructed in .NET or inspected by custom logic that traverses the dictionary, inherited properties can alter behavior (e.g., changing equality checks or type guards).
• Data injection: Keys that bypass guards may be stored as attribute names in DynamoDB, leading to unexpected query behavior or interpretation by downstream services that consume the table.

Because DynamoDB is schemaless and stores nested maps/lists, crafted attribute names can persist and later be interpreted by applications that read the item without strict schema validation. If the consuming ASP.NET code uses reflection or dynamic binding to map items back to .NET objects, polluted properties can influence object creation or method dispatch. This becomes a chain risk when combined with insecure deserialization or weak authorization checks (e.g., BOLA/IDOR), potentially enabling privilege escalation or data exposure within the table.

Remediation focuses on strict input validation, avoiding direct use of dynamic or dictionary merging on user input, and explicitly filtering dangerous keys before constructing DynamoDB requests. Below are concrete examples using the AWS SDK for .NET.

1. Validate and whitelist attributes before creating a DynamoDB item:

using Amazon.DynamoDBv2;using Amazon.DynamoDBv2.Model;using System.Collections.Generic;
using System.Linq;public class SafeTableService{ private readonly IAmazonDynamoDB _ddb; public SafeTableService(IAmazonDynamoDB ddb) { _ddb = ddb; } public async System.Threading.Tasks.Task PutItemSafeAsync(string tableName, Dictionary<string, object> input) { // Whitelist allowed top-level keys var allowed = new HashSet<string> { "UserId", "Email", "CreatedAt", "Metadata" }; var filtered = input.Where(kvp => allowed.Contains(kvp.Key)) .ToDictionary(kvp => kvp.Key, kvp => kvp.Value); // Explicitly reject keys that could lead to prototype pollution or injection if (input.Keys.Any(k => k.StartsWith("__") || k.Contains("."))) { throw new ArgumentException("Invalid attribute names."); } var request = new PutItemRequest { TableName = tableName, Item = new Dictionary<string, AttributeValue>() };
 foreach (var kvp in filtered) { request.Item[kvp.Key] = AttributeValueConverter.ToAttributeValue(kvp.Value); } await _ddb.PutItemAsync(request); }}

2. Use strongly-typed models and avoid dynamic merging:

using Amazon.DynamoDBv2.DataModel;using System.Threading.Tasks;[DynamoDBTable("Users")]public class UserItem{ [DynamoDBHashKey] public string UserId { get; set; } [DynamoDBProperty] public string Email { get; set; } [DynamoDBProperty] public string CreatedAt { get; set; } // No dynamic or object expansion from user input}public class UserRepository{ private readonly DynamoDBContext _context; public UserRepository(DynamoDBContext context) { _context = context; } public async System.Threading.Tasks.Task UpdateUserAsync(UserItem user) { // No merging of dictionaries from raw JSON; bind via model binder await _context.SaveAsync(user); }}

3. When using Document (low-level) API, sanitize attribute names explicitly:

using Amazon.DynamoDBv2;using Amazon.DynamoDBv2.Model;using System.Collections.Generic;using System.Threading.Tasks;public class DocumentSanitizer{ private readonly IAmazonDynamoDB _ddb; public DocumentSanitizer(IAmazonDynamoDB ddb) { _ddb = ddd; } public async Task PutCleanItemAsync(string tableName, Dictionary<string, object> data) { var item = new Dictionary<string, AttributeValue>(); foreach (var kvp in data) { if (string.IsNullOrWhiteSpace(kvp.Key) || kvp.Key.StartsWith("__") || kvp.Key.Contains(".")) continue; item[kvp.Key] = new AttributeValue { S = kvp.Value?.ToString() }; } var put = new PutItemRequest { TableName = tableName, Item = item }; await _ddb.PutItemAsync(put); }}

These practices ensure that user input does not dictate attribute names in DynamoDB items and that the data model remains predictable and aligned with the intended schema. Combine these with server-side validation and the middleBrick Security checks (Authentication, BOLA/IDOR, Property Authorization) to reduce the attack surface when using DynamoDB from ASP.NET applications.