Summary
Plack::App::Prerender before 0.3.0 mishandles REQUEST_URI concatenation with a rewrite base, allowing attackers to manipulate the effective target host.
When the base URL lacks a path and user-controlled request targets are appended without validation, this can lead to server-side request forgery against internal services.
Plack::App::Prerender before 0.3.0 mishandles REQUEST_URI concatenation with a rewrite base, allowing attackers to manipulate the effective target host.
When the base URL lacks a path and user-controlled request targets are appended without validation, this can lead to server-side request forgery against internal services.
Affected context
This vulnerability appears in Perl applications using Plack::App::Prerender with a rewrite base configured as a plain string URL, especially when that URL omits a path (e.g., "https://example.com").
Under these conditions, the application constructs outbound requests by concatenating the rewrite base with the raw REQUEST_URI value, without enforcing a leading slash or validating the resulting authority component.
Deployments where the webserver or application host can reach internal or restricted network resources are more exposed, as the prerender proxy can be leveraged to reach targets that are not directly accessible to external clients.
This vulnerability appears in Perl applications using Plack::App::Prerender with a rewrite base configured as a plain string URL, especially when that URL omits a path (e.g., "https://example.com").
Under these conditions, the application constructs outbound requests by concatenating the rewrite base with the raw REQUEST_URI value, without enforcing a leading slash or validating the resulting authority component.
Deployments where the webserver or application host can reach internal or restricted network resources are more exposed, as the prerender proxy can be leveraged to reach targets that are not directly accessible to external clients.
Exploit preconditions
- Attack surface: HTTP request handling path in applications that use Plack::App::Prerender as a prerendering or proxy layer.
- Required access: Ability to send crafted HTTP requests to the vulnerable application (typically unauthenticated, depending on app configuration).
- Trigger point: Construction of the proxied URL in
call, where the rewrite base string is concatenated with the REQUEST_URI value. - Why exploitation is possible: The code trusts the REQUEST_URI and appends it directly to the rewrite base without validating that it begins with "/" or that the authority/hostname remains unchanged, allowing user-controlled userinfo/host portions per RFC 3986.
- Attack surface: HTTP request handling path in applications that use Plack::App::Prerender as a prerendering or proxy layer.
- Required access: Ability to send crafted HTTP requests to the vulnerable application (typically unauthenticated, depending on app configuration).
- Trigger point: Construction of the proxied URL in
call, where the rewrite base string is concatenated with the REQUEST_URI value. - Why exploitation is possible: The code trusts the REQUEST_URI and appends it directly to the rewrite base without validating that it begins with "/" or that the authority/hostname remains unchanged, allowing user-controlled userinfo/host portions per RFC 3986.
Why this happens
The underlying bug is a classic server-side request forgery pattern where user-controlled request metadata is incorporated into backend request URLs without proper normalization or validation.
In Plack::App::Prerender, the rewrite base is treated as a simple string, and the REQUEST_URI is appended verbatim. Because the implementation does not enforce a leading slash or constrain the authority component, inputs starting with "@" are interpreted as userinfo, effectively shifting the hostname to attacker-chosen destinations.
This maps to CWE-918: Server-Side Request Forgery (SSRF), where an application uses untrusted input to construct outbound requests, enabling attackers to pivot through the server to reach otherwise inaccessible network locations.
The underlying bug is a classic server-side request forgery pattern where user-controlled request metadata is incorporated into backend request URLs without proper normalization or validation.
In Plack::App::Prerender, the rewrite base is treated as a simple string, and the REQUEST_URI is appended verbatim. Because the implementation does not enforce a leading slash or constrain the authority component, inputs starting with "@" are interpreted as userinfo, effectively shifting the hostname to attacker-chosen destinations.
This maps to CWE-918: Server-Side Request Forgery (SSRF), where an application uses untrusted input to construct outbound requests, enabling attackers to pivot through the server to reach otherwise inaccessible network locations.
Potential impact
- Attacker may access internal hosts that are reachable only from the webserver or application network.
- Attacker could read sensitive responses from restricted services (e.g., admin consoles, metadata endpoints, internal APIs).
- Attacker can perform limited port scanning or service enumeration on internal infrastructure through the prerender proxy.
- Attacker may chain SSRF with other flaws on internal systems to escalate privileges or gain remote code execution.
- Attacker may access internal hosts that are reachable only from the webserver or application network.
- Attacker could read sensitive responses from restricted services (e.g., admin consoles, metadata endpoints, internal APIs).
- Attacker can perform limited port scanning or service enumeration on internal infrastructure through the prerender proxy.
- Attacker may chain SSRF with other flaws on internal systems to escalate privileges or gain remote code execution.
General mitigation guidance
Effective mitigation focuses on constraining how client input influences backend request targets and reducing trust in any request-derived URL components.
Common defensive patterns include:
- Normalizing and validating REQUEST_URI before using it to build outbound URLs, ensuring it begins with a "/" and cannot alter the authority/hostname.
- Using structured URL-building APIs rather than string concatenation, with explicit separation of scheme, host, path, and query components.
- Restricting the set of allowable upstream hosts, enforcing an allowlist for proxy destinations instead of trusting client input.
- Applying network-layer controls so application servers cannot freely reach sensitive internal services, even if SSRF occurs.
- Designing prerendering or proxy components to operate in a locked-down context, with minimal outbound reach and least-privilege connectivity.
Effective mitigation focuses on constraining how client input influences backend request targets and reducing trust in any request-derived URL components.
Common defensive patterns include:
- Normalizing and validating REQUEST_URI before using it to build outbound URLs, ensuring it begins with a "/" and cannot alter the authority/hostname.
- Using structured URL-building APIs rather than string concatenation, with explicit separation of scheme, host, path, and query components.
- Restricting the set of allowable upstream hosts, enforcing an allowlist for proxy destinations instead of trusting client input.
- Applying network-layer controls so application servers cannot freely reach sensitive internal services, even if SSRF occurs.
- Designing prerendering or proxy components to operate in a locked-down context, with minimal outbound reach and least-privilege connectivity.
How teams detect issues like this
Detection typically combines code-level analysis with runtime monitoring:
- Static analysis rules can flag patterns where REQUEST_URI or similar request-derived fields are concatenated into outbound URLs or proxy targets.
- Manual code review should look for proxy, prerender, or HTTP client logic that builds URLs via string concatenation and does not validate the authority or path.
- Configuration reviews can identify rewrite base values that omit a path and may interact dangerously with raw request paths.
- Runtime monitoring and logging of outbound requests from the application, including full target URLs, can help spot unusual destinations or internal IPs accessed via user requests.
- Automated security testing tools configured for SSRF can probe URL-handling endpoints to detect behavior that reflects or forwards requests to attacker-controlled hosts.
Detection typically combines code-level analysis with runtime monitoring:
- Static analysis rules can flag patterns where REQUEST_URI or similar request-derived fields are concatenated into outbound URLs or proxy targets.
- Manual code review should look for proxy, prerender, or HTTP client logic that builds URLs via string concatenation and does not validate the authority or path.
- Configuration reviews can identify rewrite base values that omit a path and may interact dangerously with raw request paths.
- Runtime monitoring and logging of outbound requests from the application, including full target URLs, can help spot unusual destinations or internal IPs accessed via user requests.
- Automated security testing tools configured for SSRF can probe URL-handling endpoints to detect behavior that reflects or forwards requests to attacker-controlled hosts.
