Ssrf in Aspnet with Dynamodb

Server-Side Request Forgery (SSRF) in an ASP.NET application that interacts with Amazon DynamoDB can occur when the application constructs HTTP requests to external services based on attacker-controlled input and uses those requests while also performing DynamoDB operations. In this context, the attacker can force the server to make arbitrary internal or external HTTP calls, potentially reaching the DynamoDB endpoint itself or metadata services, bypassing network-level segregation.

An ASP.NET backend might accept a user-supplied table name or key condition, then use that input to query DynamoDB. If the same input is used to build an outbound HTTP request—such as constructing a presigned URL or calling a downstream API that returns DynamoDB data—an SSRF flaw emerges. For example, an attacker could supply a URL like http://169.254.169.254/latest/meta-data/iam/security-credentials/ as a parameter that the server uses to fetch credentials, then use those credentials to issue DynamoDB requests. Because the scan is black-box and tests unauthenticated attack surfaces, middleBrick can detect endpoints where user input influences both outbound HTTP calls and subsequent DynamoDB access patterns without authentication, exposing sensitive IAM roles or open DynamoDB endpoints.

In the context of the 12 security checks, the combination is flagged under Data Exposure and SSRF. If an unauthenticated endpoint accepts a URL parameter that directs the server to interact with DynamoDB—such as fetching a DynamoDB stream record or a table description via the AWS SDK over HTTP—the scan can identify that an attacker may pivot from a crafted request to sensitive DynamoDB metadata or exfiltrate data. The scan does not rely on internal architecture details; it observes that crafted inputs lead to unexpected service interactions and sensitive data exposure.

To mitigate SSRF when your ASP.NET application interacts with DynamoDB, validate and strictly scope all user input used to form requests or to reference DynamoDB resources. Do not allow user input to directly specify hostnames, paths, or AWS resource identifiers that can be abused to reach internal services or the DynamoDB metadata endpoint.

Use allowlists for table names and key values, and avoid concatenating user input into URLs that your server-side code will request. When calling DynamoDB, use the AWS SDK for .NET with explicit configuration and avoid building HTTP calls from raw input. The following examples show safe patterns in C# for ASP.NET.

Safe DynamoDB table name handling

Instead of using user input to form table names directly, map allowed table names to a whitelist:

using Amazon.DynamoDBv2;
using Amazon.DynamoDBv2.Model;

public class TableService
{
    private static readonly HashSet<string> AllowedTables = new() { "Users", "Products", "Orders" };
    private readonly IAmazonDynamoDB _ddb;

    public TableService(IAmazonDynamoDB ddb) => _ddb = ddb;

    public async Task<GetItemResponse> GetItemAsync(string tableKey, string partitionKeyValue)
    {
        if (!AllowedTables.Contains(tableKey))
        {
            throw new ArgumentException("Invalid table");
        }

        var request = new GetItemRequest
        {
            TableName = tableKey,
            Key = new Dictionary<string, AttributeValue>
            {
                ["Id"] = new AttributeValue { S = partitionKeyValue }
            }
        };

        return await _ddb.GetItemAsync(request);
    }
}

Safe HTTP client usage without user-supplied URLs

Do not use user input to construct request URIs for outbound calls. If you must fetch external data, use fixed endpoints and pass parameters safely:

using System.Net.Http;
using System.Threading.Tasks;

public class ExternalService
{
    private static readonly HttpClient _http = new HttpClient();
    private const string FixedEndpoint = "https://api.example.com/transform";

    public async Task<string> TransformAsync(string userContent)
    {
        var content = new FormUrlEncodedContent(new[]
        {
            new KeyValuePair<string, string>("text", userContent)
        });

        // Fixed endpoint; no user input in the URL
        var response = await _http.PostAsync(FixedEndpoint, content);
        response.EnsureSuccessStatusCode();
        return await response.Content.ReadAsStringAsync();
    }
}

Enforcing least privilege for DynamoDB access

Ensure the IAM role attached to your ASP.NET application only allows required DynamoDB actions on specific tables. Do not grant broad permissions that would allow an SSRF-induced request to perform destructive operations:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:Query"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Users"
    }
  ]
}

By combining input validation, fixed endpoints, and scoped IAM policies, you reduce the impact of SSRF in an ASP.NET application that uses DynamoDB. The middleBrick scan can verify that endpoints which accept external input do not inadvertently enable SSRF paths to DynamoDB or metadata services.