Add experimental query: SSRF host guard missing IPv6-transition unwrap (CWE-918/CWE-1389)#21950
Add experimental query: SSRF host guard missing IPv6-transition unwrap (CWE-918/CWE-1389)#21950tonghuaroot wants to merge 1 commit into
Conversation
Add javascript/ssrf-ipv6-transition-incomplete-guard, an experimental @kind problem query that flags hand-rolled SSRF host guards which reject private/loopback IPv4 ranges but never unwrap IPv6-transition forms (IPv4-mapped ::ffff:, NAT64 64:ff9b::, 6to4 2002::). Such guards can be bypassed by wrapping an internal IPv4 address in a transition literal. Includes a .qhelp with good/bad examples, a change note, and a test pack with two true-positive fixtures (private-ip package guard and a hand-written RFC 1918 denylist) and two negative-control fixtures (ipaddr.js range classifier and an explicit ::ffff: unwrap). Signed-off-by: tonghuaroot <23011166+tonghuaroot@users.noreply.github.com>
|
QHelp previews: javascript/ql/src/experimental/Security/CWE-918/SsrfIpv6TransitionIncompleteGuard.qhelpSSRF host guard does not reject IPv6-transition formsServer-side request forgery (SSRF) guards frequently reject requests to internal addresses by checking the request host against a denylist of private, loopback and cloud-metadata IPv4 ranges. When such a guard inspects only the dotted-quad IPv4 form and never unwraps IPv6-transition representations, it can be bypassed: the host validator classifies the address as public, but the operating system routes the connection to the embedded internal IPv4 endpoint. The affected forms include IPv4-mapped IPv6 ( RecommendationNormalize the host before validating it: parse the address with a transition-aware library and unwrap IPv4-mapped, NAT64 and 6to4 forms to their embedded IPv4 address, then apply the private-range check to the normalized value. Libraries such as ExampleThe following guard rejects private IPv4 ranges using the const isPrivate = require('private-ip');
const fetch = require('node-fetch');
// BAD: `private-ip` classifies the textual IPv4 form only, so it returns false
// for `::ffff:169.254.169.254`. The guard treats the wrapped internal address as
// public, but the request still reaches the metadata endpoint.
async function validateUrlHost(host) {
if (isPrivate(host)) {
throw new Error('blocked private host');
}
return fetch('http://' + host + '/');
}
module.exports = { validateUrlHost };The following guard parses the host with a transition-aware classifier, so the embedded internal IPv4 address is detected regardless of the transition form used. const ipaddr = require('ipaddr.js');
const fetch = require('node-fetch');
// GOOD: ipaddr.js parses the host and classifies it with `.range()`, which is
// transition-aware. `::ffff:169.254.169.254` parses as an IPv4-mapped address and
// is reported in the `linkLocal` range, so the guard is complete.
async function validateTargetHost(host) {
const addr = ipaddr.parse(host);
const range = addr.range();
if (range === 'private' || range === 'loopback' || range === 'linkLocal') {
throw new Error('blocked internal host');
}
return fetch('http://' + host + '/');
}
module.exports = { validateTargetHost };References
|
| @@ -0,0 +1 @@ | |||
| experimental/Security/CWE-918/SsrfIpv6TransitionIncompleteGuard.ql No newline at end of file | |||
| s.getValue().matches("%64:ff9b%") or | ||
| s.getValue().matches("%::ffff%") or | ||
| s.getValue().matches("%2002:%") or | ||
| s.getValue().matches("%2001:%") |
|
Thanks for the submission! Looks great! CI checks are currently failing since the new query filename needs to be added to this file (in sorted order): Otherwise I'd say this is good to merge. |
What
Adds a new experimental JavaScript query,
javascript/ssrf-ipv6-transition-incomplete-guard, plus a.qhelp, a change note, and a test pack.The query flags a hand-rolled SSRF host guard that rejects private/loopback IPv4 ranges but never unwraps IPv6-transition forms, so the guard can be bypassed by wrapping an internal IPv4 address in a transition literal.
Motivation
A common SSRF defense is to reject the request host against a denylist of private, loopback and cloud-metadata IPv4 ranges. When the guard inspects only the dotted-quad IPv4 form and never normalizes IPv6-transition representations, an attacker can wrap an internal address in a transition literal:
::ffff:169.254.169.25464:ff9b::a9fe:a9fe2002::new URL("http://[::ffff:169.254.169.254]/")normalizes the host, but a dotted-quad denylist (private-ip, a hand-written10./192.168./127.set,ip.isPrivate) never sees the embedded IPv4 and classifies the address as public, while the OS still routes to the internal endpoint. The Hono SSRF-protection middleware advisory GHSA-xrhx-7g5j-rcj5 is a public instance of this guard-completeness gap.Why this is a separate, experimental query
The existing CWE-918 queries (
js/request-forgery, experimentaljavascript/ssrf) are pure taint-flow: source = active threat-model source, sink = client request URL. They have no notion of a host-validation guard, so there is no notion of that guard being incomplete for IPv6-transition addresses. A target with a hand-rolled dotted-quad denylist is treated (correctly) as out of scope by the taint-flow queries; this query covers the orthogonal guard-completeness question. It is a standalone@kind problemquery and does not touch any supported query.Metadata follows the experimental rules:
@tagsincludesexperimental,security,external/cwe/cwe-918,external/cwe/cwe-1389;@security-severityand@precisionare omitted (staff-assigned). The query matches ongetName()/getValue()only — notoStringregexp matching, nogetAQlClass, no internal libraries (CONTRIBUTING §4).Tests
javascript/ql/test/experimental/Security/CWE-918/SsrfIpv6TransitionIncompleteGuard/:bad-private-ip-pkg.js—private-ippackage guard, no unwrap — flagged (true positive)bad-rfc1918-regex.js— hand-written RFC 1918 denylist — flagged (true positive)good-ipaddr.js—ipaddr.js.range()transition-aware classifier — not flaggedgood-explicit-unwrap.js— explicit::ffff:unwrap before the denylist — not flaggedcodeql test runpasses and the query compiles with no errors or warnings against the currentjavascript-allpack.