Ssrf Blind in Actix

Server-Side Request Forgery (SSRF) occurs when an application makes HTTP requests on behalf of a client without proper restrictions. In Actix web frameworks, SSRF can emerge when developers expose internal APIs or metadata endpoints (such as http://localhost, http://169.254.0.1, or internal service discovery URLs) through user-controllable parameters. A common manifestation is an unauthenticated endpoint that accepts a URL parameter and proxies the request internally without validation.

In Actix, SSRF often appears in handlers that use HttpResponse::redirect, reqwest, or hyper to fetch external or internal resources. For example, a route that renders a remote image URL or fetches a service health check based on user input may inadvertently allow an attacker to force the server to make requests to sensitive internal endpoints. This is especially dangerous in microservices architectures where internal services are exposed via HTTP and lack authentication.

Blind SSRF specifically refers to cases where the application does not return the response content directly to the attacker but instead processes it internally — such as writing to a file, triggering a webhook, or executing logic based on reachability. Attackers then infer the existence of internal services by observing side effects like delayed responses, error messages, or changes in application state. In Actix, this might be observed when a /fetch endpoint accepts a url parameter and uses reqwest::get(url) without timeout or host restrictions, allowing an attacker to probe http://169.254.169.254/latest/meta-data or http://internal-service:8080/health and detect responses via timing or error differences.

Because the attacker does not see the raw response, exploitation relies on indirect signaling. For instance, a handler might return a 200 OK if the internal service responds, or a 500 Internal Server Error if it does not — but the variation in timing or error codes can be used to enumerate services through repeated probing. In Actix applications, such behavior is often found in endpoints that perform health checks, metadata scraping, or proxy functions without input sanitization, making them ideal vectors for blind SSRF attacks.

These vulnerabilities are particularly insidious because they can bypass traditional network security assumptions. Even if internal services are behind firewalls, misconfigured routing or Docker networking can expose them to the public internet. In Actix-based APIs, failure to validate the Host header, restrict outbound connections, or validate URL schemes can allow attackers to pivot from the public API to internal systems, potentially leading to credential leakage, data exfiltration, or service enumeration.

Detecting blind SSRF in Actix applications requires understanding how user-supplied URLs are processed within request handlers. A typical vulnerable pattern involves an endpoint that accepts a url parameter and forwards the request using reqwest or hyper without validating the destination. For example:

use actix_web::{get, web, HttpResponse, Responder};

#[get("/fetch")]
async fn fetch_url(data: web::Query) -> impl Responder {
    let target = data.url.clone();
    let client = reqwest::Client::new();
    match client.get(&target).send().await {
        Ok(resp) => HttpResponse::Ok().body(resp.text().await.unwrap()),
        Err(_) => HttpResponse::InternalServerError().body("Error fetching URL"),
    }
}

This handler does not validate the URL scheme, host, or path, making it possible to request internal services. When scanned via middleBrick, such endpoints are flagged under the SSRF category with high severity. middleBrick sends crafted payloads to detectable endpoints, observes response timing, error codes, or indirect side effects (e.g., delayed responses or changes in HTTP status), and maps these behaviors to blind SSRF risk. The scanner does not rely on response content but instead detects the presence of internal service interaction by analyzing behavioral patterns across 12 parallel security checks.

During a middleBrick scan, the tool may send requests to http://169.254.169.254/latest/meta-data or http://localhost:8080/health using the vulnerable endpoint and monitor for changes in response behavior. If the application responds differently based on whether the internal endpoint is reachable — such as returning a 200 OK after a longer delay — the scanner infers blind SSRF exploitation potential. This method aligns with black-box testing principles: no credentials, no source code access, just URL submission and behavioral analysis. The resulting report includes a prioritized finding with remediation guidance and severity classification based on exploitability and impact.

Remediation of blind SSRF in Actix applications involves strict input validation, URL scheme enforcement, and network-level restrictions. Developers should avoid exposing internal endpoints through public-facing handlers and ensure that any outbound HTTP calls are limited to known, trusted destinations. A secure implementation would validate the target URL before making a request, restricting schemes to http or https, and potentially allowing only specific hosts or IP ranges.

use actix_web::{get, web, HttpResponse, Responder};
use url::Url;

#[get("/fetch")]
async fn fetch_url(data: web::Query) -> impl Responder {
    let target = data.url.clone();
    // Parse and validate URL
    let url = match Url::parse(&target) {
        Ok(u) => u,
        Err(_) => return HttpResponse::BadRequest().body("Invalid URL"),
    };
    
    // Restrict to HTTPS only
    if !matches!(url.scheme(), Some("https")) {
        return HttpResponse::BadRequest().body("Only HTTPS is allowed");
    }
    
    // Optional: whitelist specific hosts
    let allowed_hosts = vec!["api.trusted-service.com", "cdn.example.com"];
    if !allowed_hosts.contains(&url.host_str().unwrap_or("").as_str()) {
        return HttpResponse::Forbidden().body("Host not allowed");
    }
    
    let client = reqwest::Client::new();
    match client.get(&target).timeout(std::time::Duration::from_secs(5)).send().await {
        Ok(resp) => HttpResponse::Ok().body(resp.text().await.unwrap()),
        Err(_) => HttpResponse::InternalServerError().body("Failed to fetch resource"),
    }
}

Additionally, developers can leverage Actix's middleware to block requests targeting internal IP ranges. For example, intercepting requests where the target host resolves to 127.0.0.1, ::1, or cloud metadata addresses (169.254.169.254) prevents unintended access. Implementing connection timeouts and using TLS verification further reduces risk. These measures ensure that user-controlled URLs cannot be used to probe internal services, thereby eliminating the attack surface for blind SSRF.

middleBrick validates the effectiveness of such fixes by rescanning the endpoint and confirming that behavioral indicators of SSRF no longer appear. The scanner reports back with updated risk scores and ensures that findings are mapped to OWASP API Top 10 categories, such as A01:2023 - Broken Object Level Authorization or A10:2023 - Server-Side Request Forgery, providing developers with clear, actionable remediation paths.