Dns Rebinding in Axum

Q: Can I use Axum’s built-in extractors to get the client’s IP for localhost validation?

You can use axum::extract::ConnectInfo to get the peer IP address, but this is ineffective against DNS rebinding. The attack works by having the victim’s browser connect directly to your service on 127.0.0.1 (after DNS rebinding), so ConnectInfo will correctly report 127.0.0.1 . Relying on IP alone creates a false sense of security because the request appears legitimate at the network layer. The Host header, however, remains under the attacker’s control via the DNS name used in the browser request (e.g., http://attacker.com:3000 ). Therefore, IP-based checks must be combined with Host header validation. A robust approach uses both: confirm ConnectInfo shows a loopback IP and validate the Host header against an allowlist of expected hostnames for your service.

Axum-Specific Detection

Detecting DNS rebinding vulnerabilities in Axum requires checking for missing Host header validation and exposure of sensitive endpoints on wildcard interfaces. middleBrick identifies this during its unauthenticated black-box scan by probing for Host header manipulation and assessing whether internal-seeming endpoints (e.g., /debug/pprof, /actuator/shutdown) respond to requests with spoofed Host headers. It also checks if the service binds to 0.0.0.0 or :: without compensating controls. For Axum developers, manual verification involves reviewing server binding and route definitions. Look for bind("0.0.0.0") or bind("::") in your main function, then audit all routes for absence of Host-based restrictions. For instance, a route like axum::Router::new().route("/internal", get(handler)) without middleware to validate req.headers() for a known Host value is suspect. middleBrick’s scan includes a specific check for "Missing Host Header Validation" under the Property Authorization category, flagging endpoints that accept arbitrary Host values and return sensitive data. The tool correlates runtime behavior with OpenAPI specs (if provided) to highlight undocumented or internal endpoints exposed via rebinding-prone configurations.

Frequently Asked Questions

Does binding my Axum service to 127.0.0.1 alone prevent DNS rebinding?

Binding to 127.0.0.1 (or ::1) prevents external network access but does not fully mitigate DNS rebinding if the service is accessed via a reverse proxy or if the browser is used as a pivot. In DNS rebinding, the victim’s browser makes the request, so the traffic originates from localhost regardless of where the service is bound. If your Axum service is bound only to 127.0.0.1 but lacks Host header validation, a rebinding attack can still succeed because the browser resolves the attacker’s domain to 127.0.0.1 and sends the request to your service. The service sees a localhost connection and processes it. Host header validation is still required to ensure the request came from an expected origin, even on loopback interfaces.

Can I use Axum’s built-in extractors to get the client’s IP for localhost validation?

You can use axum::extract::ConnectInfo to get the peer IP address, but this is ineffective against DNS rebinding. The attack works by having the victim’s browser connect directly to your service on 127.0.0.1 (after DNS rebinding), so ConnectInfo will correctly report 127.0.0.1. Relying on IP alone creates a false sense of security because the request appears legitimate at the network layer. The Host header, however, remains under the attacker’s control via the DNS name used in the browser request (e.g., http://attacker.com:3000). Therefore, IP-based checks must be combined with Host header validation. A robust approach uses both: confirm ConnectInfo shows a loopback IP and validate the Host header against an allowlist of expected hostnames for your service.

Dns Rebinding in Axum

Axum-Specific Detection

Frequently Asked Questions

Related Pages