HIGH ssrfaspnetcockroachdb

Ssrf in Aspnet with Cockroachdb

Ssrf in Aspnet with Cockroachdb — how this specific combination creates or exposes the vulnerability

Server-Side Request Forgery (SSRF) in an ASP.NET application that uses CockroachDB can emerge when the application constructs dynamic database connection strings or queries using attacker-influenced input. If an API endpoint accepts a hostname, port, or URL parameter and uses it to build a CockroachDB connection string, an SSRF vector may allow an unauthenticated attacker to direct internal traffic from the application server.

For example, consider an endpoint that accepts a cluster_host input to connect to a CockroachDB cluster:

// Vulnerable pattern: user input flows into connection string building
var host = Request.Query["host"];
var port = Request.Query["port"] ?? "26257";
var connectionString = $"Host={host};Port={port};Database=system;SSL Mode=Disable";
using var conn = new NpgsqlConnection(connectionString);
await conn.OpenAsync();

If input validation is absent, an attacker can supply an internal address such as 169.254.169.254 (AWS instance metadata) or a Kubernetes service DNS, causing the backend to reach internal services that are not exposed externally. Although CockroachDB does not enable SSRF by itself, the way ASP.NET builds and uses connection strings can expose internal endpoints when user-supplied values influence network destinations.

Another scenario involves HTTP APIs in ASP.NET that proxy requests to a CockroachDB-compatible HTTP gateway or an internal admin interface. If the target URL is built from user input without strict allowlisting, SSRF can occur. Because CockroachDB supports HTTP APIs for certain operational endpoints, an application that forwards user-controlled paths to those endpoints can inadvertently enable SSRF.

During a middleBrick scan, findings may highlight missing input validation, missing network allowlists, and improper handling of redirects as relevant to this combination. The scanner checks for SSRF among 12 parallel security checks and surfaces the finding with severity and remediation guidance, helping you understand exposure without requiring credentials or agents.

Cockroachdb-Specific Remediation in Aspnet — concrete code fixes

Remediation focuses on strict input allowlisting, avoiding dynamic connection string assembly from untrusted input, and using configuration-driven connection management. Never concatenate user input into database connection strings or proxy targets.

1) Use static configuration for CockroachDB endpoints. Define allowed hosts and ports in configuration and reference them by name:

// appsettings.json
{
  "CockroachDb": {
    "ConnectionString": "Host=cockroach-prod.example.com;Port=26257;Database=appdb;SSL Mode=Require"
  }
}
// In Program.cs or Startup.cs
var cockroachConnection = builder.Configuration.GetConnectionString("CockroachDb");
builder.Services.AddDbContext(options =>
    NpgsqlDataSource.Create(cockroachConnection).ToDataSource());

2) If dynamic routing is required, map allowed identifiers to predefined endpoints:

// Allowed clusters defined server-side
var allowedClusters = new Dictionary
{
    ["prod"] = "Host=cockroach-prod.example.com;Port=26257;Database=appdb;SSL Mode=Require",
    ["staging"] = "Host=cockroach-staging.example.com;Port=26257;Database=appdb;SSL Mode=Require"
};

if (allowedClusters.TryGetValue(clusterKey, out var conn))
{
    using var ctx = new AppDbContext(conn);
    // safe usage
}
else
{
    Results.BadRequest("Invalid cluster identifier");
}

3) Validate and sanitize any input that could reach network paths. Use strict regex allowlists for hostnames and reject private IP ranges:

bool IsValidCockroachHost(string host)
{
    if (string.IsNullOrWhiteSpace(host)) return false;
    // Allow only DNS names; reject IPs to prevent internal routing
    return System.Text.RegularExpressions.Regex.IsMatch(host,
        @"^([a-z0-9]+(-[a-z0-9]+)*\.)+[a-z]{2,}$");
}

4) For HTTP-based administrative operations, avoid forwarding user-controlled paths. If you must interact with CockroachDB HTTP endpoints, use fixed routes and signed requests instead of dynamic composition:

// Safe: fixed endpoint with server-side authentication
var url = "https://cockroach-admin.example.com/status/vars";
using var client = new HttpClient();
client.DefaultRequestHeaders.Add("Authorization", "Bearer {serverSideToken}");
var resp = await client.GetAsync(url);

5) Apply defense-in-depth by enabling network-level controls on the server hosting ASP.NET and CockroachDB. Ensure that outbound connections to internal services are restricted by firewall rules and that CockroachDB does not listen on public interfaces unless explicitly required and protected.

middleBrick can assess these patterns as part of its 12 checks, providing prioritized findings and remediation guidance for the SSRF risk in your ASP.NET + CockroachDB setup.

Related CWEs: ssrf

CWE IDNameSeverity
CWE-918Server-Side Request Forgery (SSRF) CRITICAL
CWE-441Unintended Proxy or Intermediary (Confused Deputy) HIGH

Frequently Asked Questions

Can middleBrick detect SSRF in an ASP.NET API that uses CockroachDB without authentication?
Yes. middleBrick scans the unauthenticated attack surface and can identify SSRF indicators such as dynamic connection strings or missing input validation in ASP.NET endpoints that reference CockroachDB hosts.
Does middleBrick fix SSRF vulnerabilities in ASP.NET applications?
No. middleBrick detects and reports findings with remediation guidance, but it does not fix, patch, block, or remediate vulnerabilities. Developers should apply allowlisting, static configuration, and input validation to address SSRRF in ASP.NET + CockroachDB applications.