Ssrf Server Side in Aspnet with Mongodb

Server-side request forgery (SSRF) in an ASP.NET application that stores and retrieves data from MongoDB can occur when the server-side code accepts a URL from an attacker and uses it to form a request that reaches internal services or metadata endpoints. If the same server also holds MongoDB connection strings, credentials, or session tokens, an SSRF vector can become a pivot point to expose those secrets.

For example, an endpoint that fetches a remote image or document for processing might accept a user-provided URL, pass it to HttpClient, and then write the result into MongoDB. An attacker can supply a URL that points to the ASP.NET server’s own metadata service (e.g., http://169.254.169.254 on cloud providers) or an internal MongoDB deployment exposed only to the server (mongodb://localhost:27017). Because the request originates from the trusted server, the metadata or internal MongoDB port may be reachable, allowing enumeration of instance metadata or even attempts to interact with the database if the connection string is constructed dynamically and supplied to the MongoDB driver.

The risk is amplified when the ASP.NET app builds a MongoDB connection string using values obtained from the SSRF-vulnerable request (such as a hostname or port supplied by the user). If the application resolves a hostname via user input and then passes that to the MongoDB C# driver, the SSRF can lead to unauthorized read or write access to database collections. Moreover, SSRF can be used to probe internal endpoints that return data which the app later stores in MongoDB, effectively smuggling attacker-controlled data into the database under the guise of legitimate application behavior.

OpenAPI/Swagger spec analysis can highlight these risks by showing that an endpoint accepts arbitrary URLs and that a downstream MongoDB operation depends on values derived from that input. Runtime findings can correlate the SSRF indicators with database operations, revealing that data flows from an unvalidated external source into a sensitive storage path.

Remediation focuses on strict input validation, avoiding dynamic construction of MongoDB URIs from user input, and ensuring MongoDB operations do not depend on values derived from SSRF-prone endpoints.

• Validate and allowlist destinations: Reject any user-supplied URL that targets internal IP ranges, cloud metadata addresses, or localhost. Use Uri parsing and explicit allowlists.
• Use fixed MongoDB connection strings: Define the connection string via configuration (e.g., environment variables or Azure Key Vault), never concatenate user input into the URI.
• Parameterize database and collection names; avoid dynamic database/collection selection based on external input.

Example of a vulnerable pattern in ASP.NET (do not do this):

// Vulnerable: building MongoDB connection string with user input
var userHost = Request.Query["host"];
var client = new MongoClient(userHost); // SSRF + MongoDB risk
var database = client.GetDatabase(Request.Query["db"]);
var collection = database.GetCollection<BsonDocument>(Request.Query["collection"]);
var results = await collection.Find(new BsonDocument()).ToListAsync();
return Ok(results);

Example of a secure pattern in ASP.NET:

// Secure: fixed connection string, validated and parameterized inputs
var allowedDatabases = new HashSet<string> { "appdb", "auditdb" };
var allowedCollections = new HashSet<string> { "events", "logs" };

var dbName = Request.Query["db"];
var collectionName = Request.Query["collection"];

if (!allowedDatabases.Contains(dbName) || !allowedCollections.Contains(collectionName))
{
    return BadRequest("Invalid database or collection");
}

// Fixed connection string from configuration
var client = new MongoClient(Configuration.GetConnectionString("MongoDb"));
var database = client.GetDatabase(dbName);
var collection = database.GetCollection<BsonDocument>(collectionName);

// Use a controlled filter, not raw user input
var filter = Builders<BsonDocument>.Filter.Empty;
var results = await collection.Find(filter).ToListAsync();
return Ok(results);

Additional measures include using network-level isolation to prevent the ASP.NET server from reaching internal MongoDB instances unless explicitly required, and applying the principle of least privilege to the MongoDB user account used by the application. When integrating with middleBrick, you can use the CLI to scan from terminal with middlebrick scan <url> or add API security checks to your CI/CD pipeline via the GitHub Action to detect SSRF and MongoDB-related misconfigurations before deployment.