qprobe: refuse a URL as a URL, not as a CIDR block - #51
Merged
Conversation
`qprobe --i-own-this https://example.com` failed with refusing CIDR block "https://example.com" - qProbe probes one host at a time, not ranges. The slash check ran before anything else, so every URL was reported as a range sweep: an error describing a mistake the operator had not made, and one that gave no hint about the fix. It cost a real probe run on a tracked repo. URLs are still refused, because a target is one named host, but now for the right reason and with the host to use: refusing URL "https://example.com/health" - qProbe takes a host, not a URL. Try: example.com A slash is only reported as a CIDR block when it is actually a prefix length (10.0.0.0/24); a pasted path says so instead. A target carrying credentials is refused explicitly, and the suggestion names the host it would really have connected to - --i-own-this is an ownership attestation, so a target that reads as one host and resolves to another must not be accepted quietly. The suggestion is for the message only. Nothing is newly accepted: the refusals that are security controls (CIDR, ranges, wildcards, lists) still throw before any network I/O.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A probe run on a tracked repo failed with:
The
raw.includes("/")check ran before anything else, so every URL was reported as a range sweep. The message described a mistake the operator had not made and gave no hint about the fix. That cost a real run.What changes
URLs are still refused — a target is one named host — but for the right reason, and the message names the host to use:
10.0.0.0/24). A pasted path (example.com/blog) says path instead.mine.com@theirs.com) is refused explicitly, and the suggestion names the host it would really have connected to.--i-own-thisis an ownership attestation, so a target that reads as one host and resolves to another must not be accepted quietly — and if you are going to refuse it, showing which host it actually resolves to is the useful part.What does not change
The suggestion is for the message only. Nothing is newly accepted. The refusals that are security controls — CIDR blocks, IP ranges, wildcards, lists — still throw before any network I/O, and there is a test asserting the CIDR path still reports as CIDR so this cannot be loosened by accident.
I deliberately did not make qProbe accept URLs and normalise them internally.
parseTarget's stated stance is that the refusal is a security control rather than a convenience check, and silently resolvinghttps://mine.com@theirs.com/totheirs.comwould widen what--i-own-thisattests to. The website generating the workflow normalises instead, where the resolved host is visible in the committed file.SemVer: patch. Message and classification only.
Verified
npm run build,npm run lint,npm run format:check,npm testacross all 8 packages, 0 failures. qprobe's own suite goes 49 → 55 tests: URL-not-CIDR with the suggested host, path vs real CIDR, credentials, non-https schemes, and the plain forms still parsing.Also documents in
--helpand the README that a target is a host, not a URL, since the interface never actually said so.Related
quantakrypto/website#118 strips the scheme when generating the probe workflow, so the bad target cannot be produced from the dashboard in the first place. This is the other half: the tool explaining itself correctly when someone types one by hand.