[
https://issues.apache.org/jira/browse/TAP5-2832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ben Weidig reassigned TAP5-2832:
--------------------------------
Assignee: Ben Weidig
> LocalHostOnly doesn't identify some IPv6 localhost variants
> -----------------------------------------------------------
>
> Key: TAP5-2832
> URL: https://issues.apache.org/jira/browse/TAP5-2832
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Reporter: Ben Weidig
> Assignee: Ben Weidig
> Priority: Minor
>
> h1. Description
> The current implementation for checking if a request originates from
> {{localhost}} relies on string comparisons against a hardcoded list of
> loopback addresses:
> * {{localhost}}
> * {{127.0.0.1}}
> * {{0:0:0:0:0:0:0:1%0}}
> * {{0:0:0:0:0:0:0:1}}
> Furthermore, using {{HttpServletRequest.getRemoteHost()}} has potential
> performance implications.
> h1. Why This is an Issue
> h2. Performance Risk
> {{HttpServletRequest.getRemoteHost()}} is designed to return the fully
> qualified domain name of the client.
> If the servlet container's DNS lookup is enabled, calling this method will
> trigger a synchronous reverse DNS lookup.
> If the DNS server is slow or unreachable, this will block the request thread,
> leading to severe latency or thread pool exhaustion.
> h2. Arbitrary Scope IDs (Zone IDs)
> The check specifically looks for the scope ID {{%0}}
> ({{{}0:0:0:0:0:0:0:1%0{}}}).
> However, scope IDs are determined dynamically by the client operating system
> and network interface.
> On Linux/macOS, it could be {{%lo}} or {{{}%eth0{}}}, on Windows, it might be
> {{%12}} or {{{}%5{}}}.
> If the scope ID is anything other than `%0`, the check fails.
> h2. Missing Compressed IPv6 Addresses
> Depending on client environment configurations or the presence of reverse
> proxies (e.g., Nginx, HAProxy) passing headers, the IP address can be
> returned in its compressed form ({{{}::1{}}}), which is currently not matched.
> h2. Missing IPv4-mapped IPv6 Addresses
> In dual-stack environments, IPv4 loopback requests might be mapped to IPv6
> format, appearing as {{{}::ffff:127.0.0.1{}}}.
> The current code will fail to recognize this as a local request.
> h1. Proposed Solution
> We should switch to {{getRemoteAddr()}} to avoid reverse DNS resolution
> lookup penalties, strip off any arbitrary scope IDs, and use Java's native
> {{InetAddress}} class to reliably evaluate if the IP is a loopback address.
> That would require exposing the {{HttpServletRequest}} to
> {{WhitelistAnalyzer}} in some form.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
