zwanski2019/zwanski-Bug-Bounty

GitHub: zwanski2019/zwanski-Bug-Bounty

一套以业务逻辑驱动的 Bug Bounty 侦察与漏洞利用方法论框架,附带本地命令中心和 AI 辅助流水线。

Stars: 0 | Forks: 0

# zwanski Bug Bounty 方法论 [![GitHub stars](https://img.shields.io/github/stars/zwanski2019/zwanski-Bug-Bounty?style=for-the-badge&logo=github)](https://github.com/zwanski2019/zwanski-Bug-Bounty/stargazers) [![GitHub forks](https://img.shields.io/github/forks/zwanski2019/zwanski-Bug-Bounty?style=for-the-badge&logo=github)](https://github.com/zwanski2019/zwanski-Bug-Bounty/network/members) [![License](https://img.shields.io/github/license/zwanski2019/zwanski-Bug-Bounty?style=for-the-badge)](https://github.com/zwanski2019/zwanski-Bug-Bounty/blob/main/LICENSE) 由从业者构建的、带有明确倾向的侦察与漏洞利用方法论,专注于**大多数猎人会忽略的环节**。 这不是一份工具列表,也不是一份检查清单,而是一个由实际发现作为支撑的思维框架。 **文档:** [仓库内 Wiki](docs/wiki/README.md) · [QUICKSTART.md](QUICKSTART.md) · [INSTALL.md](INSTALL.md) · [PRODUCTION.md](PRODUCTION.md) · [DOCKER.md](DOCKER.md) ## ZWANSKI.BB 命令中心 (本地仪表盘) 本仓库包含一个基于 **Flask + Socket.IO** 的 Web 界面(`ui/index.html`, `server.py`)——一个集成了工具、代理、AI、遥测以及可选 **Zwanski Watchdog** 集成的统一操作面板。 ### 启动 ``` zwanski start ``` 打开 **http://localhost:1337** (或在 `.env` 中设置 `PORT`)。 ### UI 包含内容 | 区域 | 功能说明 | |------|----------------| | **Command (命令)** | 作战地图 (`/api/warmap`),扫描/重启快捷方式 | | **Telemetry (遥测)** | 主机健康状态 + 进程 (`/api/system/*`) | | **Agentic (智能体)** | 多阶段侦察流水线 (`/api/agent/*`) | | **Arsenal (武器库)** | 工具注册表,命令预览,子域名/OAuth 链 | | **Watchdog (看门狗)** | `zwanski-watchdog/` 的状态及白名单任务(Docker 基础设施、`pnpm` 开发服务器、扫描器) — [wiki](docs/wiki/watchdog.md) | | **Terminal (终端)** | xterm 统一流 + 基于 tmux 的并行会话控制 (`/api/term/sessions`) | | **Intel AI (情报 AI)** | 聊天、评分、KB/RAG、漏洞利用链提示(兼容 OpenRouter) | | **Reports (报告)** | 报告定稿 API | | **Config (配置)** | 会话 AI 覆盖配置;`SHADOW_MODE`、`AUTO_GIT_SYNC` 的说明以及安装向导重新启动 | ### 首次启动设置向导 在首次启动仪表盘时,ZWANSKI.BB 会打开一个引导式设置向导,用于检查必需和推荐的先决条件(工具、API 密钥和运行时依赖项)。 清单中的每一项都支持**安装**、**配置**或**跳过**,用户可以通过 **Config → Run setup wizard** 重新执行该流程。 向导 API: - `GET /api/setup/checklist` - `POST /api/setup/decision` - `POST /api/setup/complete` ### Watchdog 环境(可选) 如果您在非默认端口上运行 Watchdog 栈,请在 `.env` 中设置: - `WATCHDOG_API_URL`(默认 `http://127.0.0.1:4000`) - `WATCHDOG_WEB_URL`(默认 `http://127.0.0.1:3000`) - `WATCHDOG_CLASSIFIER_URL`(默认 `http://127.0.0.1:8001`) 完整 API 表:[docs/wiki/api.md](docs/wiki/api.md)。 ## 功能特性 - 针对现代 Web、API、OAuth/OIDC 和移动端目标的倾向性 Bug Bounty 方法论 - 带有作战地图、统一终端、系统遥测和代理流水线的**命令中心** - **Zwanski Watchdog** 选项卡:探测 API/Web/分类器并启动有文档记录的基础设施和开发命令(无任意 shell 执行) - 本地 **KB / RAG** 钩子以及 AI 辅助评分、链式分析和报告流程 - 用于移动 C2 对齐的 **OpenClaw 桥接**清单(`openclaw_bridge.json`,`GET /api/openclaw/commands`) - 带有可选 Go 工具链辅助的一键安装器(`install.sh`,`setup-tools.sh`) - **影子模式**(`SHADOW_MODE=1`),用于在流水线内探测时产生抖动的 HTTP 客户端行为 - 从画像分析到报告的整洁分阶段工作流(`00-setup/` … `08-reporting/`) ## 方法论概述 本方法论被设计为一个链条:业务逻辑、侦察、认证面、漏洞类别、环境渗透、移动/API 关联以及报告。每个阶段都建立在前一个阶段之上,使您始终将范围、上下文和影响放在首位。 ## 为什么与众不同 大多数公开的方法论都止步于此: `subfinder → httpx → nuclei → ???` 而本方法论在其他方法结束的地方开始: - **业务逻辑先于技术** — 在运行任何工具之前,先了解收入流和数据信任关系 - **信任边界映射** — 寻找身份验证决策实际发生的地方,而不是文档中声称的地方 - **二阶链** — 输入 → 存储 → 异步处理 → 输出,这才是真正的高危漏洞所在 - **环境渗透** — staging/UAT/dev 环境是一个金矿,而大多数猎人完全忽略了它们 - **OAuth/OIDC 恶意客户端链** — 几乎没有人能正确报告的 CVSS 9+ 漏洞类别 - **AI/LLM 攻击面** — 2025-2026 年项目中一块很大程度上未被认领的领地 - **供应链侦察** — 包泄露、GitHub Actions 密钥、依赖混淆 ## 结构 ``` 00-setup/ → Toolchain, environment, API keys 01-target-profiling/ → Business model, scope analysis, threat model BEFORE tools 02-passive-recon/ → OSINT, GitHub dorking, historical, supply chain 03-active-recon/ → Subdomain enum, port scan, tech fingerprint, API discovery 04-auth-surface/ → OAuth/OIDC mapping, session analysis, MFA bypass vectors 05-vuln-classes/ → Business logic, race conditions, second-order, tenant isolation, GraphQL, WebSockets, AI/LLM surface 06-environment-bleed/ → Staging-prod correlation, CI/CD exposure 07-mobile-api/ → APK/IPA recon, endpoint correlation with web surface 08-reporting/ → Report templates, CVSS guidance, chain documentation scripts/ → Automation: scope parser, subdomain chain, auth flow mapper zwanski-watchdog/ → Optional leak-pipeline monorepo (scanner, API, web, classifier) docs/wiki/ → In-repo wiki (dashboard, API, Watchdog, configuration) ``` ## 阶段流程 ``` TARGET ASSIGNED │ ▼ [01] Profiling ──► Understand the business. What data is valuable? Who are the user tiers? │ What's the revenue model? What would embarrass them? ▼ [02] Passive ────► No packets to target. OSINT, GitHub, historical, supply chain. │ ▼ [03] Active ─────► Subdomain enum → live hosts → tech stack → API discovery → JS analysis │ ▼ [04] Auth Surface ► OAuth flows, SSO chains, session lifecycle, privilege boundaries │ ▼ [05] Vuln Classes ► Target-specific: pick the classes that match the stack │ ▼ [06] Env Bleed ──► Staging/dev/UAT correlation. Often skipped. Often critical. │ ▼ [07] Mobile/API ─► Cross-reference mobile endpoints with web surface │ ▼ [08] Report ─────► Chain findings, calculate real business impact, draft write-up ``` ## 核心思维 **1. 假设外围防御已经加固,直接攻击逻辑。** WAF 会拦截你的 `