CodeQL alert #23 (go/request-forgery, CWE-918 SSRF) flagged the
client.Do(req) sink at internal/service/scep_probe.go:232 because
the URL parameter to scepHTTPGet is taint-traced from the user-
supplied input to ProbeSCEP without the analyzer recognizing the
upstream sanitizer.
The defense-in-depth was already in place:
1. validation.ValidateSafeURL at ProbeSCEP entry (line 75) —
rejects obvious SSRF targets (loopback / link-local / cloud
metadata literals) before any network call.
2. validation.SafeHTTPDialContext on the http.Transport —
re-resolves the host at dial time and rejects connections to
reserved IP ranges. This is the authoritative SSRF + DNS-
rebinding guard. Even if step 1 was bypassed, the dial would
still fail.
But CodeQL's taint tracker doesn't follow the validator across
function boundaries, so the alert stays open even though the code
is safe. This commit re-runs validation.ValidateSafeURL inside
scepHTTPGet immediately before http.NewRequestWithContext —
sanitizer in the same function as the sink, which CodeQL
recognizes as a guard.
Bonus defense-in-depth: any future call site that wires a URL
into scepHTTPGet without going through ProbeSCEP (e.g. a new code
path that directly probes a discovered URL) inherits the same
SSRF guard automatically. Fail-closed by default.
The validator dispatch matches ProbeSCEP's pattern — tests
override via s.scepValidateURL to hit httptest loopback servers;
production callers use validation.ValidateSafeURL. The probe's
existing httptest-based tests continue to work unchanged.
Verified locally:
gofmt: clean.
go vet ./...: exit 0.
go test -short ./internal/service/...: ok 4.029s
(every existing scep_probe test still green — the new
revalidation is a no-op for tests that go through ProbeSCEP
because the same validator already passed once at entry).
Reference: https://github.com/certctl-io/certctl/security/code-scanning/23
Closes CodeQL alert #23 (go/request-forgery).
shankar0123
e6919cdaba