[
https://issues.apache.org/jira/browse/TAP5-2832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18092524#comment-18092524
]
ASF subversion and git services commented on TAP5-2832:
-------------------------------------------------------
Commit 291ab2aacf6c26c98f77fa013ba3408c9a9f4dd6 in tapestry-5's branch
refs/heads/master from Jarek Potiuk
[ https://gitbox.apache.org/repos/asf?p=tapestry-5.git;h=291ab2aac ]
Add draft threat model + SECURITY.md + AGENTS.md for security-model
discoverability (#61)
* Add draft THREAT_MODEL.md + SECURITY.md + AGENTS.md for security-model
discoverability
Adds a draft (v0) threat model plus SECURITY.md and AGENTS.md so an automated
scan agent can discover the model via AGENTS.md -> SECURITY.md ->
THREAT_MODEL.md.
The model is a proposal for the PMC to review; most claims are (inferred) and
route to open questions in its section 14.
Generated-by: Claude Code (Claude Opus 4.8)
* THREAT_MODEL.md: broaden test-code exclusion per PMC review
thiagohp (PR #61): exclude all internal test code (src/test/** across
modules, not just tapestry-core/src/test/app1) — none of it deploys.
Generalized §2/§3/§11a accordingly.
Generated-by: Claude Opus 4.8
* Fold PMC review answers (PR #61): Q1-Q5 — HMAC-unset is loud-error not
fail-closed (TAP5-2834 planned), escaping default + writeRaw/OutputRaw opt-in,
asset traversal via container+own checks, LocalhostOnly +
@Secure/secure-enabled (TAP5-2832 IPv6 bug), and no built-in CSRF (app
responsibility)
> 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
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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)
