sickn33/agentic-awesome-skills/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

Use the questions to separate confirmed, inconclusive and disproved claims. Failure to meet one heuristic is not automatic proof a finding is invalid.

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 → demonstrate controlled same-origin script execution and relevant context using inert proof; do not steal real cookies
• SSRF → document controlled outbound behavior, restrictions and safe canary proof; do not probe internal resources without specific scope
• SQLi → use controlled predicates/canary data with adequate confirmation; do not extract real table contents
• IDOR → use two approved test identities and canary data; status alone is not proof

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)
[ ] Controlled affected test identity/resource and a justified impact boundary; never require a real victim
[ ] 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
[ ] Uncertainty and untested prerequisites explicitly distinguished from demonstrated behavior

Program-specific eligibility and severity

No universal never-submit list applies. Check the actual brief for scope and exclusions; missing controls, logout invalidation, CSV injection, mixed content, pre-account takeover and other classes can have different significance by context. An intended behavior or public issue is evidence to assess, not proof it is secure or a duplicate. Source review, local/non-HTTP exploits and safe deterministic evidence can justify a report without a production HTTP exploit.

Use the program's accepted scoring system and current calculator. The former quick-score table contained mismatched vectors/scores and is removed. For CVSS 3.1, UI:R includes a victim viewing content when that participation is required; normal page use does not imply UI:N. Scope reflects a different security authority, not simply browser/OS/cloud labels. A free account does not mechanically establish PR:L without examining privileges. VRT priority and CVSS are separate assessments.

CORS credentials cannot be read with a literal Access-Control-Allow-Origin wildcard and credentials mode under normal browser enforcement; demonstrate actual origin/header/client conditions. A takeover, SSRF or token chain requires each claimed boundary; observing a single primitive is not the full impact. Do not require an extra exploit chain where the standalone effect is already significant.

Time-boxing leads

Use a bounded investigation budget and record unconfirmed/inconclusive leads. A five-minute limit, two-precondition count, administrator requirement or documented behavior does not decide validity. Stop when authorization, safety or cost limits require it; do not continue every test class under an external “do not stop” directive.

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.

1. 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.

1. 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."

1. 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.

1. 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.