triage-validation – skill Viết lách & Nội dung cho agent AI

> ⚠️ 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 witho

… (nội dung đầy đủ có trong gói tải về)