Triage Validation

⚠️ AUTHORIZED USE ONLY This skill is for educational purposes or authorized security assessments only. You must have explicit, written permission from the system owner before using this tool. Misuse of this tool is illegal and strictly prohibited.

Mandatory confirmation gate Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

1. Ask the user to state the exact target URL, IP, account, or resource.
2. Ask the user to confirm written authorization and the permitted scope.
3. Show the exact command(s) and explain their expected effect.
4. Wait for explicit confirmation in the current conversation.

Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

TRIAGE & VALIDATION

One wrong answer = STOP this finding. Kill the finding. Move on to the next test class.

Scope of "STOP" in this skill: This skill's gates kill INDIVIDUAL FINDINGS that fail validation. They do NOT authorize stopping the engagement. Killing a finding via the 7-Question Gate just means that finding doesn't get submitted — every other test class in the engagement is still pending. See redteam-mindset "DO NOT STOP primary directive" for the coverage-axis rule.

"N/A hurts your validity ratio. Informative is neutral. Only submit what passes all 7 questions."

THE 7-QUESTION GATE

Ask IN ORDER. One wrong answer = STOP immediately.

Q1: Can an attacker use this RIGHT NOW, step by step?

Complete this template:

1. Setup:   I need [own account / another user's ID / no account]
2. Request: [exact HTTP method, URL, headers, body — copy-paste ready]
3. Result:  I can [read / modify / delete] [exact data shown in response]
4. Impact:  The real-world consequence is [account takeover / PII read / money stolen]
5. Cost:    Time: [X minutes], Capital: [$0 / $X subscription required]

If you CANNOT write step 2 as a real HTTP request → KILL IT.

Q2: Is the impact on the program's accepted impact list?

Go to the program page. Find "Vulnerability Types" or "Out of Scope."

Common tiers:

• Critical: Any-user ATO without interaction, RCE, SQLi with data exfil, admin auth bypass
• High: Mass PII exfil, privilege escalation, internal SSRF with data, stored XSS all users
• Medium: IDOR on specific user non-critical data, XSS on sensitive page requiring click
• Low: Non-sensitive info disclosure, clickjacking with PoC

If your bug maps to a listed exclusion → KILL IT.

Q3: Is the root cause in an in-scope asset?

Confirm:

• Vulnerable domain is on the in-scope list (not *.internal.target.com)
• It's a production asset (not staging/dev unless explicitly in scope)
• It's not a third-party service the company just uses (not Stripe, Salesforce, Google Auth)

If out-of-scope → KILL IT.

Q4: Does it require privileged access that an attacker can't realistically get?

• "Admin can do X" = centralization risk = KILL IT (on 99% of programs)
• "Non-admin can do X that only admin should do" = valid
• "Requires physical access / MFA device" = usually invalid
• "Requires compromised victim account to work" = questionable, low severity at best

Q5: Is this already known or accepted behavior?

Search:

1. Program's HackerOne/Bugcrowd disclosed reports: Ctrl+F endpoint name + bug class
2. GitHub issues on target repo: is:issue label:security ENDPOINT_NAME
3. Changelog/CHANGELOG.md — does it mention this behavior?
4. API docs / design docs — is it documented as intended?

If acknowledged/design decision → KILL IT.

Q6: Can you prove impact beyond "technically possible"?

• XSS → show actual cookie theft or session hijack, not just alert(1) or alert(document.domain)
• SSRF → hit an internal endpoint that returns data, not just DNS ping
• SQLi → show actual data exfil from a real table, not just error message
• IDOR → show actual other-user's data in response, not just a 200 status code

If you can only show "technically possible" → DOWNGRADE severity, not kill.

Q7: Is this a known-invalid bug class?

Check the NEVER SUBMIT list below. If it's on this list without a chain → KILL IT.

THE LAYER-ORDERING TRAP — read before claiming any auth bypass

A validation error does NOT prove you passed authentication.

This is the highest-confidence false positive in the auth-bypass class, because the evidence looks concrete. The reasoning that fails:

"I sent an unauthenticated request and got back 400 — field X is required. A validation error means the request cleared auth and reached business logic. Therefore auth is missing."

That inference is only valid if auth runs before input handling. Many stacks put a global input sanitiser, body parser, or schema filter in front of the auth middleware. A malformed body is then rejected before auth is ever consulted, and the response is indistinguishable from "auth passed, validation failed."

The test: re-send with a minimal WELL-FORMED body.

# malformed body — trips the sanitiser, which runs FIRST
curl -s -X POST https://target/api/v1/resource -d '{'
# 400 {"code":"ERR-INPUT-0001","message":"Invalid text. Only permitted
#      characters are allowed"}                      <- looks like auth bypass

# same endpoint, well-formed empty object — now auth is reached
curl -s -X POST https://target/api/v1/resource -H 'Content-Type: application/json' -d '{}'
# 401 {"code":"ERR-AUTH-0001","message":"Not authenticated. Please log in."}

Only the second response tells you where the auth layer sits.

Lesson from an authorized engagement. On a production API, a malformed body returned a validation-shaped 400 on the large majority of endpoints tested. Read as an auth bypass, that is a Critical filed against production infrastructure covering financial and administrative operations. It was a sanitiser reacting to the { character before auth ran — every one of those endpoints returned 401 to a well-formed {}. The false Critical was avoided only because someone re-tested.

Rules:

• Layer ordering is not observable from a single response. Never infer it.
• Probe auth with the simplest valid body the parser will accept, not a malformed one.
• If the error text is about input shape or character class, you are talking to a parser or sanitiser, not to business logic.
• If the error text names a domain field (accountId is required) AND a well-formed body still returns it, that is a real signal — proceed to Q6.
• Applies equally to WAF and CDN layers: an edge block is not an origin response.

4 PRE-SUBMISSION GATES

Run in sequence. ALL 4 must PASS.

Gate 0: Reality Check (30 seconds)

[ ] Bug is REAL — confirmed with actual HTTP requests, not code reading alone
[ ] Bug is IN SCOPE — checked program scope page explicitly
[ ] Reproducible from scratch — can reproduce starting from fresh session
[ ] Evidence ready — screenshot, response body, or video

Gate 1: Impact Validation (2 minutes)

[ ] Can answer: "What can attacker DO that they couldn't before?"
[ ] Answer is more than "see non-sensitive data" (unless program pays for info disclosure)
[ ] Real victim: another user's data, company's data, financial loss
[ ] Not relying on victim doing something unlikely

Gate 2: Deduplication Check (5 minutes)

[ ] Searched HackerOne Hacktivity for this program + similar bug title/endpoint
[ ] Searched GitHub issues for target repo
[ ] Read most recent 5 disclosed reports for this program
[ ] Not a "known issue" in their changelog or public docs
[ ] Google: "TARGET_NAME ENDPOINT_NAME bug bounty"

Gate 3: Report Quality (10 minutes)

[ ] Title: [Bug Class] in [Endpoint] allows [actor] to [impact]
[ ] Steps to Reproduce: copy-pasteable HTTP request
[ ] Evidence: screenshot/video of actual impact (not just 200 status)
[ ] Severity: matches CVSS 3.1 score AND program's severity definitions
[ ] Remediation: 1-2 sentences of concrete fix
[ ] NEVER used "could potentially" or "may allow"

NEVER SUBMIT LIST

Submitting these destroys your validity ratio.

Missing CSP / HSTS / security headers
Missing SPF / DKIM / DMARC
GraphQL introspection alone (no auth bypass, no IDOR demonstrated)
Banner / version disclosure without working CVE exploit
Clickjacking on non-sensitive pages (no sensitive action PoC)
Tabnabbing
CSV injection (no actual code execution shown)
CORS wildcard (*) without credential exfil proof of concept
Logout CSRF
Self-XSS (only exploits own account)
Open redirect alone (no ATO or OAuth theft chain)
OAuth client_secret in mobile app (known, expected)
SSRF DNS callback only (no internal service access or data)
Host header injection alone (no password reset poisoning PoC)
Rate limit on non-critical forms (search, contact, login with Cloudflare)
Session not invalidated on logout
Concurrent sessions
Internal IP in error message
Mixed content
SSL weak ciphers
Missing HttpOnly / Secure cookie flags alone
Broken external links
Autocomplete on password fields
Pre-account takeover (usually — very specific conditions required)

CONDITIONALLY VALID — CHAIN REQUIRED

Build the chain first, prove it works end to end, THEN report.

CVSS 3.1 QUICK REFERENCE

Common Score Examples

UI for stored XSS is a judgment call. Stored XSS that fires on page view is a long-standing CVSS gray area — NVD/FIRST frequently score it UI:R (which drops the stored-XSS row above to ~7.6). The UI:N above models "no extra action beyond normal page use"; if your triager expects UI:R, defend the choice or re-score before copying the number into a report.

Metric Quick Guide

KILL FAST RULES

The goal is to QUICKLY disqualify bad leads so you hunt real bugs:

1. 5-minute rule: If you can't fill in Q1's template in 5 minutes → move on
2. Precondition count: More than 2 preconditions simultaneously required → kill it
3. Impact test: "What does attacker walk away with?" — if nothing tangible → kill it
4. Admin bypass: "Admin can do X" is NEVER a bug → kill it immediately
5. Design doc test: If it's documented behavior → kill it immediately
6. Rabbit hole signal: 30+ min on Q6 with no reproducible PoC → kill it

PRE-SEVERITY GATE

Before labelling any finding Critical or High anywhere in your notes or report — write out the answer to each of these as a one-liner. If you can't answer concretely, the severity is wrong.

1. Have I validated the FULL chain to attacker-attainable impact, or only one primitive in the middle? — "Primitive confirmed at layer N" ≠ exploitable. Multi-stage chains require ALL stages validated before the severity matches the chain's top end.
2. What does the attacker walk away with, in one concrete sentence? — "RCE on the SP front-end web server" is concrete. "Could lead to RCE" is not — that's High at best, often Medium.
3. Have I personally reproduced the full chain end-to-end at least twice? — Twice = once during discovery, once for the report screenshot/PoC. Not "I'm sure it would work."
4. Is there an inheritance gate, signature check, audience check, or other validation step still gating the chain? — If yes, the chain is not Critical. Document it as "primitive present" at lower severity until the gate is bypassed.
5. Has the program rejected this severity class before? — Many programs cap "info disclosure with no concrete impact" at Low/Info regardless of the data type. Read the program scope.

Lesson from an authorized engagement: JWT alg:none was initially labelled Critical based on the signature-bypass primitive being confirmed at the audience-validation layer. Subsequent testing showed the issuer-trust check still rejected unsigned tokens — the full ATO chain did not complete. Finding had to be retracted. If the Pre-Severity Gate had been run on the original draft, Q1 would have killed the Critical label before submission.