Bb local toolkit

--- name: bb-local-toolkit description: Comprehensive bug bounty workflow : reconnaissance (subdomain enumeration, asset discovery, fingerprinting, HackerOne scope, source code audit), pre-hunt preparation (disclosed reports, tech stack research, mind maps, threat modeling), vulnerability hunting (IDOR, SSRF, XSS, auth bypass, CSRF, race conditions, SQLi, XXE, file upload, business logic, GraphQL, HTTP smuggling, cache poisoning, OAuth, timing side-channels, OIDC, SSTI, subdomain takeover, cloud misconfiguration, ATO chains, agentic AI), LLM/AI security testing (chatbot IDOR, prompt injection, indirect injection, ASCII smuggling, exfiltration channels, RCE via code tools, system-prompt-extraction, ASI01:ASI10), A-to-B bug chaining (IDOR→auth bypass, SSRF→cloud metadata, XSS→ATO, open redirect→OAuth theft, S3→bundle→secret→OAuth), bypass tables (SSRF IP bypass, open redirect bypass, file upload bypass), language-specific grep (JS prototype pollution, Python pickle, PHP type juggling, Go template.HTML, RubyYAML.loads, Rust unwrap), and reporting (7-Question Gate, 4 validation gates, human-tone writing, templates by vulnerability class, CVSS 3.1, PoC generation, always-rejected list, conditional chain table, submission checklist). Use for ANY bug bounty task:starting a new target, conducting reconnaissance, hunting for specific vulnerabilities, auditing source code, testing AI features, validating findings, or writing reports. Chinese trigger words: bug bounty, security testing, penetration testing, vulnerability hunting, information gathering, subdomain enumeration, XSS testing, SQL injection, SSRF, security audit, vulnerability reporting --- # Bug Bounty Master Workflow Full pipeline: Recon -> Learn -> Hunt -> Validate -> Report. One-skills for everything. ## THE ONLY QUESTION THAT MATTERS > "Can an attacker do this RIGHT NOW against a real user who has taken NO unusual actions:and does it cause real harm (stolen money, leaked PII, account takeover, code execution)?" > > If the answer is NO -- STOP. Do not write a report. Do not investigate further. Move on. ### Theoretical Bug = Wasted Time. Eliminate These Immediately: | Pattern | Reason to Eliminate | |---|---| | "Could theoretically allow..." | Not exploitable = not a bug | | "An attacker with X, Y, Z conditions could..." | Too many preconditions | | "Wrong implementation but no practical impact" | Wrong but harmless = not a bug | | Dead code containing a bug | Not reachable = not a bug | | Source maps without secrets | No impact | | SSRF with DNS-only callback | Requires data exfiltration or internal access | | Open redirect alone | Requires ATO or OAuth chain | | "Could be used in a chain if..." | Build the chain first, THEN report | You must demonstrate actual harm. "Could" is not a bug. Prove it works or drop it. --- ## CRITICAL RULES 1. READ THE FULL SCOPE FIRST -- verify that every asset/domain is owned by the target organization 2. NO THEORETICAL BUGS -- "Can an attacker steal funds, leak PII, take over an account, or execute code RIGHT NOW?" If not, STOP. 3. ELIMINATE WEAK FINDINGS QUICKLY -- run the 7-Question Gate BEFORE writing any report 4. Validate before writing -- check the CHANGELOG, design docs, and deployment scripts FIRST 5. One bug class at a time : dig deep, don’t cast a wide net 6. Verify data isn’t already public : check the web UI in incognito mode before reporting API “leaks” 7. 5-MINUTE RULE -- if a target reveals nothing after 5 minutes of probing (all 401/403/404 responses), MOVE ON 8. IMPACT-FIRST HUNTING -- ask, “What’s the worst-case scenario if authentication were compromised?” If nothing valuable is at risk, skip the target 9. CREDENTIAL LEAKS require proof of exploitation -- finding keys isn’t enough; you must PROVE what they grant access to 10. STOP SHALLOW RECON SPIRALS -- don’t probe 403s, don’t grep for analytics keys, don’t check staging domains that lead nowhere 11. BUSINESS IMPACT over vulnerability class -- severity depends on CONTEXT, not just vulnerability type 12. UNDERSTAND THE TARGET DEEPLY -- before hunting, learn the app like a real user 13. DON’T OVER-RELY ON AUTOMATION -- automated scans hit WAFs, trigger rate limits, and find the same bugs everyone else finds 14. HUNT LESS-SATURATED VULNERABILITY CLASSES : XSS/SSRF/XXE face the most competition. Expand into: cache poisoning, Android/mobile vulnerabilities, business logic, race conditions, OAuth/OIDC chains, CI/CD pipeline attacks 15. ONE-HOUR RULE -- Stuck on one target for an hour with no progress? SWITCH CONTEX