kamakauzy/BurpProxyForge

# ProxyForge [](https://github.com/kamakauzy/BurpProxyForge/actions/workflows/build-and-release.yml) [](https://github.com/kamakauzy/BurpProxyForge/releases/latest) [](https://github.com/kamakauzy/BurpProxyForge/releases) ProxyForge 是一个 Burp Suite Professional 扩展，用于在 Burp 内部管理和轮换上游云支持代理。它提供了一个专用的基于 Montoya 的 Burp 标签页、一个本地路由代理、AWS Fireprox、Cloudflare Flareprox 和基于 VPS 代理的提供商面板，以及一个轮换引擎，让 Burp 流量通过管理的代理池传输。 brad@securit360.com https://www.securit360.com/ - 我们做渗透测试!! ## 亮点 - Java 21 + Montoya API 扩展，打包为单个 `ProxyForge.jar` - 基于 Swing 的 Burp 标签页，包含： - AWS Fireprox 面板 - Cloudflare Flareprox 面板 - VPS Forge 面板 - Proxy Pool (代理池) 表格 - Rotation Engine (轮换引擎) 控件 - Scope-based routing (基于作用域的路由) 表格 - 嵌入式日志面板 - 本地 HTTP 代理监听器，监听可配置端口 (默认 `127.0.0.1:8081`) - 轮换策略： - Random (随机) - Round-Robin (轮询) - Least-Used (最少使用) - Sticky-per-host (按主机粘性) - Per-scope rule (按作用域规则) - Provider lifecycle actions (提供商生命周期操作)： - Deploy (部署) - List (列出) - Delete (删除) - Provider (提供商) 操作使用提供的凭据创建和管理真实的云资源 - 直接从 Burp 部署、列出、验证和删除实时提供商端点 - Burp 卸载时自动清理 - 通过 Montoya 持久化机制保存设置、代理池和作用域规则 ## 架构 ProxyForge 现在使用混合路由架构： 1. Burp 通过一条上游代理规则将出站流量发送到本地 ProxyForge 监听器： - 当存在支持 CONNECT 的上游代理时，ProxyForge 可以从扩展内部为您管理这条 Burp 项目级上游代理规则 - 默认管理目标：`127.0.0.1:8081` 2. 对于 VPS / HTTP / SOCKS 代理条目： - 本地监听器从池中选择一个支持 CONNECT 的上游代理 - Burp 流量正常通过该上游代理转发 3. 对于 Fireprox / Flareprox 转发器条目： - ProxyForge 在 Burp 内部将匹配的请求重写为提供商端点，然后再发送到本地监听器 - 本地监听器检测到这些重写后的转发器主机，并直接连接它们而不是重新轮换 4. Provider (提供商) 状态、日志、请求计数、验证状态和作用域映射显示在 Burp 标签页中。 ### 组件 - `burp.ProxyForgeExtension` - Burp 入口点和生命周期管理器 - `proxyforge.ui.ProxyForgeTab` - Swing UI 和用户工作流 - `proxyforge.providers.ProviderRegistry` - AWS, Cloudflare 和 VPS 配置的提供商适配器 - `proxyforge.proxy.LocalProxyServer` - 本地代理监听器和请求转发 - `proxyforge.proxy.ProxyRotationEngine` - 池选择、粘性和作用域路由 - `proxyforge.models.ProxyForgeModels` - 持久化数据模型 - `proxyforge.utils.*` - 日志、持久化、JSON、HTTP 助手 ## 提供商支持 ### AWS Fireprox - 输入： - Access Key (访问密钥) - Secret Key (秘密密钥) - Session Token (会话令牌，可选) - Region (区域) - Target URL (目标 URL) - 部署： - 使用 AWS SDK v2 API Gateway REST APIs - 创建根 `ANY /` 和贪婪 `ANY /{proxy+}` HTTP 代理集成 - 部署到 `proxy` 阶段 - 将部署的 API Gateway 端点添加到代理池 ### Cloudflare Flareprox - 输入： - API Token (API 令牌) - Account ID (账户 ID) - Workers Subdomain (Workers 子域名，仅输入账户子域名，而非完整的 `workers.dev` URL) - Target URL (目标 URL，包含 scheme 并输入真实的上游应用 URL) - 部署： - 通过 Cloudflare Workers API 上传 Worker 脚本 - 为部署的脚本启用公共 `workers.dev` 路由 - 在将公共端点添加到代理池之前验证它 - 返回已部署脚本的经过验证的 `workers.dev` 端点 ### VPS Forge - 输入： - Vendor (供应商：`DigitalOcean`, `Linode`, `AWS EC2`) - API Token (API 令牌) - Region (区域) - Instance Type (实例类型) - 可选的 AWS 专用基础设施字段 (用于 EC2) - 部署： - DigitalOcean 和 Linode 使用提供商 API 配合 cloud-init 引导 `tinyproxy` 实例 - 当提供所需的基础设施字段时，AWS EC2 支持启动/终止 - 将配置好的代理端点添加到池中 ## 构建 ### 前置条件 - Java 21 - 网络访问权限 (用于 Gradle 依赖解析) ### 预构建下载 如果您只需要可安装的 jar，则无需在本地构建 ProxyForge。 - **GitHub Releases** - 维护者可以发布版本标签，例如 `v1.0.1`。 - GitHub Actions 发布工作流会自动将 `ProxyForge.jar` 附加到该版本。 - 最终用户可以直接从仓库的 **Releases** 页面下载 jar。 - **GitHub Actions artifacts** - 每次推送、拉取请求和手动工作流运行都会上传一个 `ProxyForge.jar` artifact。 - 在仓库的 **Actions** 标签页下打开相关运行，并下载 `ProxyForge-` artifact。 - 这对于在标记正式版本之前测试分支构建很有用。 ### 命令 ``` ./gradlew clean fatJar test ``` 构建产物： - Extension JAR: `build/libs/ProxyForge.jar` - Plain JAR: `build/libs/ProxyForge-plain.jar` - Test reports: `build/reports/tests/test/index.html` ## 版本控制和变更日志流程 ProxyForge 使用轻量级 semver + GitHub Releases 流程。 - 发布标签使用 `vMAJOR.MINOR.PATCH` 格式，例如 `v1.0.1`。 - 标签构建将标签版本传递给 Gradle，以便打包的 jar 清单与 GitHub Release 版本匹配。 - GitHub Releases 是已发布构建的权威变更日志。 - GitHub 自动生成的发布说明由 `.github/release.yml` 分类。 推荐的 PR 标签： - `breaking` -> major release (主要版本) - `feature` -> minor release (次要版本) - `bug` -> patch release (补丁版本) - `maintenance` -> patch release (补丁版本) - `docs` -> 仅文档或低影响的补丁工作 - `skip-changelog` -> 从发布说明中排除 推荐的维护者发布流程： 1. 将标记的拉取请求合并到主分支。 2. 根据影响最大的合并标签确定下一个语义版本。 3. 创建并推送标签，例如 `v1.0.1`。 4. GitHub Actions 构建 `ProxyForge.jar`，发布 GitHub Release，并附加 jar 资产。 ## 在 Burp Suite Professional 中加载 您可以从 **GitHub Releases / Actions artifacts** 下载预构建的 `ProxyForge.jar`，或者在本地构建它。 1. 如果您想自己构建项目： ./gradlew clean fatJar test 2. 打开 Burp Suite Professional。 3. 转到 **Extensions**。 4. 添加一个新的 **Java** 扩展。 5. 选择下载的 `ProxyForge.jar` 或本地构建的 `build/libs/ProxyForge.jar`。 6. 确认扩展已加载并且 **ProxyForge** 标签页出现。 ## 快速入门 1. 打开 **ProxyForge** 标签页。 2. 在其中一个提供商面板中输入有效的提供商凭据。 3. 填写必填的部署字段： - AWS: access key, secret key, region, target URL - Cloudflare: API token, account ID, workers subdomain, target URL - VPS: vendor, API token, region, instance type 4. 点击 **Deploy**。 5. 在 **Rotation Engine** 中，保持默认本地端口 `8081`。 6. 点击 **Start / Restart Proxy**。 7. 如果您希望 ProxyForge 在存在支持 CONNECT 的上游代理时自动添加 Burp 项目级规则，请启用 **Burp upstream rule**。 8. 使用作用域规则或目标主机匹配来决定请求是否应使用： - 转发器条目 (Fireprox / Flareprox)，或 - 支持 CONNECT 的上游代理 (VPS / HTTP / SOCKS) 9. 点击 **Validate All**。 10. 使用 **Rotate Now** 强制切换下一个上游代理候选项。 ## 使用指南 ### Provider (提供商) 工作流 - **Deploy** - 创建提供商端点并将其添加到代理池。 - **List** - 获取匹配的远程提供商对象并将其合并到本地池中。 - **Delete Selected** - 删除当前突出显示的条目并触发提供商清理。 ### Proxy Pool (代理池) 池表格显示： - status (状态) - provider (提供商) - proxy type (代理类型) - endpoint (端点) - creation time (创建时间) - requests served (已服务请求) - last error (最后错误) 您可以： - 启用或禁用条目 - 删除选定的条目 - 刷新表格 ### Rotation Engine (轮换引擎) - **Random** - 随机选择一个健康的上游代理或转发器候选项 - **Round-Robin** - 顺序轮换 - **Least-Used** - 选择 `requestsServed` 最低的 - **Sticky-per-host** - 对重复主机保持相同路由 - **Per-scope rule** - 在回退之前遵守作用域表映射 ### Scope-based routing (基于作用域的路由) 规则支持： - 简单主机名 - 通配符主机模式匹配 - 正则表达式模式 - 固定代理分配 - 提供商偏好分配 混合路由行为： - 如果规则解析为 AWS Fireprox 或 Cloudflare Flareprox 条目，ProxyForge 会在 Burp 内部将请求重写为该转发器端点。 - 如果规则解析为 VPS / HTTP / SOCKS 条目，本地代理将通过该上游代理转发流量。 - 如果没有转发器规则匹配，ProxyForge 将回退到上游代理通道。 ### Validation (验证) `Validate All` 执行： - HTTP/SOCKS 池条目的直接连接检查 - 转发器端点的 HTTP 可达性检查 - 基于对已部署端点的连接检查的实时健康结果 ## 持久化和密钥 - 设置、池条目、提供商表单值和作用域规则在 Burp 重启后保留。 - 敏感提供商值默认保存在内存中。 - 如果启用了 **Persist provider secrets**，当前表单字段将通过 Burp 的持久化层作为扩展状态的一部分写入。 - 如果启用了 **Burp upstream rule**，当池中存在支持 CONNECT 的上游代理时，ProxyForge 会管理 Burp 项目级上游规则，并在禁用或卸载时将其移除。 - 扩展卸载时运行自动清理。 ## 本地代理行为 - 监听器默认绑定到 `127.0.0.1`。 - 可选的外部绑定可用于高级实验室设置。 - 标准 HTTP 上游代理支持普通 HTTP 转发和 `CONNECT` 隧道。 - SOCKS5 条目支持出站普通 HTTP 转发和 `CONNECT` 隧道。 - Fireprox 和 Flareprox 条目被视为转发器，而不是通用的上游 CONNECT 代理。 - 匹配的请求在 Burp 内部被重写为提供商端点，本地监听器绕过对这些重写转发器主机的重新轮换。 ## 测试 项目包含一个自动化冒烟测试，该测试： - 启动本地上游 HTTP 代理测试固件， - 启动本地 ProxyForge 监听器， - 通过 ProxyForge 端口发送普通 HTTP 请求， - 验证请求是否正确转发，以及 - 验证轮询选择行为。 运行： ``` ./gradlew test ``` ## 截图说明 以下视图用于 BApp 提交截图： 1. **Main tab overview** (主标签页概览) - 左侧显示提供商标签，右侧显示代理池，右上角显示轮换引擎 2. **AWS panel with a live Fireprox deployment** (带有实时 Fireprox 部署的 AWS 面板) - 显示目标 URL、区域和结果部署的 Fireprox 端点 3. **Proxy pool with multiple providers** (具有多个提供商代理池) - 显示混合的 AWS、Cloudflare 和 VPS 条目及其请求计数器 4. **Scope rule editor and validation results** (作用域规则编辑器和验证结果) - 显示主机模式路由规则和 `Validate All` 后更新的健康状态 5. **Logging panel** (日志面板) - 显示提供商生命周期操作和代理事件 ## BApp 提交说明 此处包含的仓库提交资产： - `README.md` - `bapp.json` - `BappManifest.bmf` - 完整源代码 - Gradle wrapper - 通过 `ProxyForge.jar` 进行单次安装 JAR 打包 审核者的推荐构建命令： ``` ./gradlew clean fatJar test ``` 维护者发布流程： 1. 正常推送提交以生成可下载的 Actions artifacts。 2. 使用 `breaking`, `feature`, `bug`, `maintenance`, `docs`, 或 `skip-changelog` 标记更改。 3. 创建并推送语义版本标签，例如 `v1.0.1`。 4. GitHub Actions 将构建 `ProxyForge.jar`，发布 GitHub Release，并附带分类后的发布说明 jar。 ## 项目布局 ``` src/main/java/burp src/main/java/proxyforge/ui src/main/java/proxyforge/providers src/main/java/proxyforge/proxy src/main/java/proxyforge/models src/main/java/proxyforge/utils src/main/resources/worker src/main/resources/templates ```

标签：AWS Fireprox, Burp Suite 插件, Cloudflare Flareprox, HTTP 代理, IP 轮换, Montoya API, VPS 代理, Web 安全, 云代理, 代理池, 代理管理, 后台面板检测, 域名枚举, 安全测试, 攻击性安全, 流量路由, 源 IP 隐藏, 特权提升, 网络安全, 网络管理, 自动化部署, 规避检测, 隐私保护