Ssrf Server Side in Aspnet with Dynamodb

Server-side request forgery (SSRF) in an ASP.NET application that interacts with Amazon DynamoDB can arise when the application constructs HTTP requests to external services based on attacker-controlled input and uses those requests while also performing DynamoDB operations. For example, if an endpoint accepts a URL intended for a backend resource and uses it to fetch data before writing metadata or results into a DynamoDB table, an attacker can supply a malicious internal endpoint (e.g., http://169.254.169.254/latest/meta-data/iam/security-credentials/) or a malicious service that returns crafted responses. The application may then process the response and store findings or state in DynamoDB, exposing internal services or credentials through the data flow between the HTTP request and the database.

In the context of middleBrick’s checks, SSRF is one of the 12 parallel security checks. The scanner tests unauthenticated attack surfaces and can detect whether outbound HTTP requests from the API can be influenced to reach internal endpoints. When the API also writes to DynamoDB, the risk is compounded because sensitive discovery results (such as retrieved instance metadata or exfiltrated data) may be persisted, increasing exposure. The scanner’s LLM/AI Security checks further probe whether prompt injection or data exfiltration attempts can travel through such SSRF paths and influence LLM endpoints or cause cost exploitation, with findings mapped to frameworks like OWASP API Top 10 and SOC2.

An example scenario: an ASP.NET Core controller accepts a target hostname, performs an HTTP GET to that host, and stores the response size and a tag in a DynamoDB item. If the hostname is not validated and can point to internal AWS metadata service, the application may leak IAM credentials. Those credentials could then be used to perform unauthorized DynamoDB operations, and any injected payloads could be stored and later reflected in other outputs. This illustrates how SSRF and DynamoDB usage intersect: user input influences the HTTP request, the request outcome is trusted, and the results are persisted in a structured database.

Remediation focuses on input validation, strict endpoint allowlisting, and avoiding the use of untrusted input in HTTP requests that may affect DynamoDB operations. In ASP.NET, use model validation and explicit allowlists for hostnames or paths that the application is designed to query. When performing HTTP calls, prefer whitelisted internal services or approved external APIs, and avoid forwarding user-supplied URLs directly. Ensure that any data written to DynamoDB does not include raw user-provided URLs or response bodies without normalization and inspection.

Use the AWS SDK for .NET to interact with DynamoDB safely. Validate and parameterize all inputs, and avoid concatenating strings to form table names or keys. Below are concrete, working .NET examples that demonstrate secure patterns.

using System;
using System.Threading.Tasks;
using Amazon.DynamoDBv2;
using Amazon.DynamoDBv2.Model;
using Microsoft.AspNetCore.Mvc;

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

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

    // Secure: explicit input model with validation, parameterized DynamoDB access
    [HttpPost("store")]
    public async Task StoreItemAsync([FromBody] ItemRequest request)
    {
        if (!ModelState.IsValid)
        {
            return BadRequest(ModelState);
        }

        // Validate and restrict allowed characters to prevent injection
        if (!System.Text.RegularExpressions.Regex.IsMatch(request.Id, @"^[a-zA-Z0-9\-_]+$"))
        {
            return BadRequest("Invalid item ID.");
        }

        var putRequest = new PutItemRequest
        {
            TableName = "Items", // hardcoded or from configuration; never user-supplied
            Item = new System.Collections.Generic.Dictionary<string, AttributeValue>
            {
                { "Id", new AttributeValue { S = request.Id } },
                { "Name", new AttributeValue { S = request.Name } },
                { "Metadata", new AttributeValue { S = request.Metadata } }
            }
        };

        await _dynamoDb.PutItemAsync(putRequest);
        return Ok();
    }

    // Secure: parameterized query with validation; avoid raw user input in key expressions
    [HttpGet("lookup")]
    public async Task<IActionResult> LookupItemAsync([FromQuery] string id)
    {
        if (string.IsNullOrWhiteSpace(id) || !System.Text.RegularExpressions.Regex.IsMatch(id, @"^[a-zA-Z0-9\-_]+$"))
        {
            return BadRequest("Invalid lookup ID.");
        }

        var getRequest = new GetItemRequest
        {
            TableName = "Items",
            Key = new System.Collections.Generic.Dictionary<string, AttributeValue>
            {
                { "Id", new AttributeValue { S = id } }
            }
        };

        var response = await _dynamoDb.GetItemAsync(getRequest);
        if (response.Item == null || response.Item.Count == 0)
        {
            return NotFound();
        }

        return Ok(response.Item);
    }
}

public class ItemRequest
{
    public string Id { get; set; }
    public string Name { get; set; }
    public string Metadata { get; set; }
}

Complement these practices by validating HTTP targets if your API performs outbound calls. Use a strict allowlist for permitted hosts, disable automatic redirection to internal IPs, and set timeouts to limit hanging connections. Do not store raw user-provided URLs in DynamoDB; if metadata must be retained, sanitize and normalize it. These measures reduce the attack surface for SSRF and ensure that DynamoDB-stored data remains trustworthy and aligned with compliance mappings such as OWASP API Top 10 and SOC2.