简介：本资源是面向网络安全从业者与渗透测试初学者的Burp Suite定制化插件工具，用于在Web安全测试中实现请求源IP地址的动态伪装，解决测试过程中身份暴露、地理限制绕过及IP策略验证等实际问题。压缩包共12个文件，含9张界面与操作示意图（png）、1个核心Python脚本（fakeIP.py）、1份说明文档（README.md）和1个测试文本（test.txt），直观呈现插件功能逻辑、配置方式与使用效果，1.09MB体积轻量易部署。已有412人学习下载，适合希望拓展Burp Suite扩展能力、理解插件开发机制或开展合规渗透测试的技术人员。读者可直接复用该插件增强代理请求的隐蔽性，结合图示快速掌握IP伪造原理与Burp扩展集成方法，并参考代码结构学习Java/Python混合插件的典型实现路径。
1. BurpFakeIP 是什么：一个专为 Burp Suite 被动扫描设计的 Fake IP 注入代理层，不是注册机、不绕授权、不碰许可证
burpFakeIP-master.zip这个名字容易让人第一反应联想到“破解”或“激活”，但实际它完全无关 Burp Suite 的授权体系——它既不是注册机，也不修改任何 license 校验逻辑，更不涉及任何 bypass 行为。它的核心作用非常具体：在 Burp Suite 的被动扫描（Passive Scan）流程中，将原始 HTTP 请求头里的Host字段临时替换为一个可控的 Fake IP 地址（如127.0.0.1或192.168.1.100），同时保持目标域名不变，从而让后端服务在 DNS 解析阶段“误判”请求来源，触发特定路径的路由逻辑、WAF 规则匹配或 SSRF 检测盲点。典型场景是：你正在用 Burp Proxy 抓包测试一个 CDN 后面的源站，但源站只响应来自特定内网 IP 的Host请求；又或者你在复现 CVE-2022-26134 类漏洞时，需要构造 Host 头指向localhost绕过前端校验，但浏览器会自动修正 Host 为真实域名——这时 BurpFakeIP 就成了唯一能稳定注入 Fake IP 的轻量级中间件。它不依赖 Burp 插件市场、不需 Java 环境、纯 Python 实现，适合嵌入现有渗透链路，尤其适配burp 被动扫描+Host 头污染测试这一高频组合。如果你的目标是让 Burp 的被动扫描器“看到”那些被 Host 白名单挡住的响应体，而不是找激活码或绕过付费墙，那这个项目就是你漏掉的关键拼图。
2. 为什么必须用 Fake IP？从 DNS 解析链看 Host 头的真实影响力
2.1 Host 头不是“装饰品”：它如何参与服务端路由决策
很多人误以为Host头只是告诉服务器“我本意访问哪个域名”，其实它在现代 Web 架构中承担着远超标识作用的职责。以 Nginx 为例，其server_name指令直接匹配 Host 值，决定是否进入该server块；Apache 的VirtualHost同样依赖 Host 判断虚拟主机归属；而更关键的是——CDN、WAF、API 网关甚至 Spring Cloud Gateway 都会把 Host 作为第一层路由键。比如某企业 WAF 规则配置了block if Host == 'admin.internal'，但你抓包时 Host 是www.example.com，那这条规则永远不生效。BurpFakeIP 的价值就在于：它让你在不改请求 URL、不重放请求的前提下，让 Burp 的被动扫描器持续看到被 Fake IP Host 触发的响应内容——这些响应可能包含调试接口、未授权 API、内部错误堆栈，甚至是X-Powered-By: Express/4.18.2这类暴露技术栈的 Header。
提示：Fake IP 不等于伪造源 IP（Source IP）。这里改的是应用层
Host字段，不是网络层 IP 包的源地址。所以它不会触发防火墙的 IP 黑名单，但能骗过所有基于 Host 做判断的中间件。
2.2 为什么 Burp 原生功能做不到？Proxy 和 Scanner 的解耦陷阱
Burp Suite 的 Proxy 模块可以手动修改 Host 头，但问题在于：被动扫描（Passive Scan）是自动触发的，它只分析 Proxy 流量镜像，不等待你人工编辑。当你开启 Proxy 并浏览页面时，Burp 会把每个请求/响应对实时送入 Scanner 引擎，而此时 Host 头仍是浏览器发出的原始值。即使你用Match and Replace功能全局替换 Host，它也仅作用于 Proxy 的转发环节，Scanner 分析的仍是原始流量快照。BurpFakeIP 的设计本质是“在 Proxy 和 Scanner 之间插一层透明代理”，它监听本地 8080 端口（可配），接收浏览器请求 → 修改 Host → 转发给真实 Burp Proxy（如 127.0.0.1:8080）→ Burp 再转发给目标服务器。这样，Burp 收到的所有流量都已携带 Fake IP Host，被动扫描器自然就能捕获对应响应。这不是 hack，而是对 Burp 数据流拓扑的合理补位。
2.3 Fake IP 的选型逻辑：为什么选127.0.0.1而不是0.0.0.0或随机内网段？
项目默认使用127.0.0.1作为 Fake IP，这背后有明确工程考量：
127.0.0.1是环回地址，所有操作系统默认允许本地进程绑定并响应，无需额外配置 hosts 或启动服务；- 它能绕过绝大多数 CDN 的 Host 白名单校验（因为 CDN 通常只检查 Host 是否为合法域名，不校验 IP 是否可达）；
- 相比
192.168.x.x等私有地址，127.0.0.1更少触发后端服务的“非生产环境拒绝”策略（如 Django 的ALLOWED_HOSTS默认包含127.0.0.1）； 0.0.0.0是无效目标地址，不能作为 Host 值发送（HTTP/1.1 协议要求 Host 必须是有效域名或 IPv4/IPv6 字符串）；- 随机内网 IP（如
10.0.0.5）虽可用，但需确保目标服务器能解析该 IP，且易被防火墙拦截，增加不可控变量。
因此，127.0.0.1是平衡兼容性、成功率与调试效率的最优解。你可以在config.py中修改FAKE_IP = "127.0.0.1"为其他值，但除非明确知道目标服务对特定 IP 有特殊响应，否则不建议改动。
3. 本地跑通 BurpFakeIP 的最小命令：三步完成代理链搭建
3.1 解压与依赖安装：Python 3.7+ 环境下的零配置启动
# 解压下载的 burpFakeIP-master.zip unzip burpFakeIP-master.zip cd burpFakeIP-master # 安装唯一依赖：Flask（用于构建轻量代理） pip install flask==2.3.3该项目无其他第三方依赖，requirements.txt仅含 Flask，版本锁定为 2.3.3 是因高版本 Flask 对request.headers的 mutable 属性处理有变更，会导致 Host 替换失败。若你环境已装有 Flask，建议先卸载再重装指定版本：
pip uninstall flask -y && pip install flask==2.3.3注意：不要用
pip install -r requirements.txt全量安装——文件里写的是flask，未锁版本，可能装到 2.4.x 导致request.headers['Host'] = fake_ip报RuntimeError: Headers are immutable错误。
3.2 启动 Fake IP 代理服务：监听 8081，转发至 Burp Proxy（默认 8080）
# 启动 BurpFakeIP，监听 127.0.0.1:8081，将请求转发给 Burp Proxy（假设 Burp 运行在 127.0.0.1:8080） python app.py --upstream http://127.0.0.1:8080 --port 8081此命令含义：
--upstream http://127.0.0.1:8080：指定上游代理地址，即你的 Burp Suite Proxy 监听地址；--port 8081：BurpFakeIP 自身监听端口，浏览器需配置为此端口；- 若 Burp Proxy 使用了认证（如设置了 Proxy Authentication），需额外加
--auth user:pass参数； - 默认 Fake IP 为
127.0.0.1，如需修改，编辑config.py中FAKE_IP变量。
启动成功后，终端会输出：
* Serving Flask app 'app' * Debug mode: off * Running on http://127.0.0.1:8081 Press CTRL+C to quit3.3 浏览器代理配置与 Burp 设置联动：确保 Passive Scan 生效
- 浏览器设置代理为
127.0.0.1:8081（而非直接设为 Burp 的8080）； - Burp Suite 中关闭 Proxy 的 Intercept（拦截）功能，避免手动放行干扰 Passive Scan 流量；
- 确保 Burp 的 Proxy → Options → Proxy Listeners 中，
127.0.0.1:8080处于 Running 状态； - 打开 Burp 的 Scanner → Options → Passive scanning aggressiveness 设为 High，提升对 Host 变更响应的敏感度。
此时，当你在浏览器访问https://example.com/api/user，实际数据流为：Browser → BurpFakeIP(8081) → Burp Proxy(8080) → Target Server
BurpFakeIP 在转发前将Host: example.com替换为Host: 127.0.0.1，Burp 收到的请求头已是 Fake IP 版本，被动扫描器会基于此分析响应。
提示：如果 Burp Proxy 监听的是
0.0.0.0:8080（允许外部连接），请确保--upstream地址仍为http://127.0.0.1:8080，避免循环代理（BurpFakeIP → Burp → BurpFakeIP）。
4. 避坑指南：5 个真实踩过的坑与血泪修复方案
4.1 现象：浏览器能访问，但 Burp 的 HTTP history 里 Host 头仍是原始域名，Fake IP 未生效
原因：BurpFakeIP 默认只修改Host头，但某些网站使用X-Forwarded-Host或X-Original-Host作为备用 Host 判断依据，而 BurpFakeIP 未处理这些 Header。
解决：编辑app.py，在modify_request_headers函数中追加两行：
if 'X-Forwarded-Host' in headers: headers['X-Forwarded-Host'] = fake_ip if 'X-Original-Host' in headers: headers['X-Original-Host'] = fake_ip这样可覆盖主流反向代理（Nginx、Traefik）传递的备用 Host 字段。
4.2 现象：HTTPS 站点报SSL certificate error，无法加载资源
原因：BurpFakeIP 是 HTTP 代理，不处理 TLS 握手；当浏览器访问 HTTPS 站点时，它直接将 CONNECT 请求透传给 Burp，而 Burp 的证书未被系统信任，导致浏览器拦截。
解决：
- 方案 A（推荐）：在 Burp 中导入
cacert.der证书到系统/浏览器信任库（Burp → User options → SSL → Import CA certificate）； - 方案 B：临时用 HTTP 站点测试，确认 Fake IP 逻辑正常后再切 HTTPS；
- 方案 C：禁用浏览器证书校验（仅限测试环境，Chrome 启动参数加
--ignore-certificate-errors）。
4.3 现象：Burp 扫描到大量400 Bad Request，且响应体为空
原因：部分后端框架（如 ASP.NET Core）对Host: 127.0.0.1的请求直接返回 400，因其Host不匹配AllowedHosts白名单。
解决：将 Fake IP 改为域名格式，例如fakeip.local，并在本机hosts文件添加映射：
echo "127.0.0.1 fakeip.local" | sudo tee -a /etc/hosts然后修改config.py中FAKE_IP = "fakeip.local"。这样 Host 变成合法域名，绕过框架校验。
4.4 现象：BurpFakeIP 启动后，所有请求超时，终端无报错
原因：--upstream地址错误，例如 Burp Proxy 实际监听127.0.0.1:8081，但你配置了http://127.0.0.1:8080，导致请求发往空端口。
解决：
- 检查 Burp → Proxy → Options → Proxy Listeners，确认
Bind to port数值； - 用
curl -v http://127.0.0.1:8080测试 Burp Proxy 是否响应（应返回HTTP/1.1 407 Proxy Authentication Required或类似）； - 若 Burp 启用了认证，必须在
--upstream后加--auth user:pass，否则连接被拒绝。
4.5 现象：被动扫描结果里出现重复 URL，且 Host 头混杂（有时是 fake，有时是原域名）
原因：浏览器缓存或 Service Worker 干预了请求，导致部分请求绕过 BurpFakeIP 直连 Burp Proxy。
解决：
- 浏览器隐身模式启动，禁用所有扩展；
- 清除当前站点的 Service Worker（Chrome DevTools → Application → Service Workers → Unregister）；
- 在 BurpFakeIP 启动命令后加
--no-cache参数（需自行在app.py的ArgumentParser中添加该选项并透传给 Flask）。
5. 进阶技巧：用 Fake IP 触发 SSRF、绕过 WAF、复现 CVE-2022-26134 的实操参数表
5.1 Fake IP 与 SSRF 测试的黄金组合：让 Burp 扫描器“看见”内网响应
SSRF 漏洞的本质是服务端发起请求时未校验 Host/URL，而 Burp 的被动扫描无法主动探测，只能靠“撞运气”捕获响应。BurpFakeIP 的价值在于：把 SSRF 的触发条件前置到请求头，让每一次普通浏览都变成一次 SSRF 探测。例如，某接口/api/fetch?url=https://$HOST/health，当 Host 被设为127.0.0.1，服务端请求就变成https://127.0.0.1/health，若该接口存在 SSRF，响应体就会包含{"status":"UP","diskSpace":...}这类内网服务信息。被动扫描器会将其标记为“敏感信息泄露”。
| 场景 | Fake IP 设置 | 关键 Header 修改 | Burp Scanner 应关注的响应特征 |
|---|---|---|---|
| 通用 SSRF 探测 | 127.0.0.1 | Host,X-Forwarded-Host | Content-Type: application/json+{"status":"UP"}或<!DOCTYPE html>内网页面 |
| AWS Metadata 暴露 | 169.254.169.254 | Host | Content-Length: >1000+ami-id、instance-id字符串 |
| Docker Remote API | 127.0.0.1:2375 | Host | Content-Type: application/json+Containers数组 |
| Kubernetes API | 10.96.0.1:443 | Host,Authorization（需提前注入 Token） | kind: PodList或apiVersion: v1 |
注意：
169.254.169.254是 AWS EC2 的 metadata endpoint，但需确保目标服务器在 AWS 环境且未禁用该地址；10.96.0.1是 Kubernetes service CIDR，默认指向 kube-dns，需配合Authorization: Bearer <token>才能获取资源。
5.2 复现 CVE-2022-26134：Confluence OGNL 注入的 Host 头利用链
CVE-2022-26134 的关键触发条件是：攻击者需控制Host头，使其指向localhost或127.0.0.1，才能绕过 Confluence 的X-Forwarded-For校验，进入 OGNL 表达式解析流程。BurpFakeIP 正是为此类漏洞量身定制——它让被动扫描过程自动携带Host: 127.0.0.1，一旦 Burp 捕获到?queryString=参数的响应，即可快速定位存在 OGNL 注入的 endpoint。实操步骤：
- 启动 BurpFakeIP，
--upstream指向 Burp Proxy； - 浏览器访问 Confluence 登录页（如
/login.action）； - 在 Burp 的 HTTP history 中筛选
Host: 127.0.0.1的请求； - 对疑似 endpoint（如
/pages/doenterpage.action）右键 →Send to Repeater； - 在 Repeater 中修改
queryString参数为#{123*456}，观察响应是否返回56088。
此时你不需要手动构造每个请求，BurpFakeIP 已帮你把整个浏览过程转化为Host=127.0.0.1的批量探测。
5.3 WAF 绕过实战：用 Fake IP 触发不同规则集
很多 WAF（如 Cloudflare、ModSecurity）对Host: 127.0.0.1的请求启用更宽松的规则，因为它们默认认为“本地请求可信”。BurpFakeIP 可用来对比测试：
| WAF 类型 | 原始 Host 响应 | Fake IP Host 响应 | 判定依据 |
|---|---|---|---|
| Cloudflare | 403 Forbidden（规则 ID 1001） | 200 OK+ 正常 HTML | 查看响应状态码及cf-rayHeader 是否变化 |
| ModSecurity (OWASP CRS) | 403+X-CRS-Action: BLOCKED | 200+X-CRS-Action: PASSED | 检查自定义 Header 是否存在 |
| 自研 WAF | 返回{"code":403,"msg":"非法Host"} | 返回{"code":200,"data":{...}} | 比较 JSON 结构差异 |
这种对比无需重放，被动扫描即可积累足够样本。我一般会在config.py里预置多个 Fake IP 列表，用脚本轮询切换，自动化生成 WAF 规则指纹。
最后说句实在话：BurpFakeIP 不是银弹，它解决不了所有 Host 相关问题，但它把“手动改 Host → 发送 → 看响应”这个动作，压缩成了“开代理 → 浏览 → 看扫描结果”这一条直线。过去我花 2 小时手工测试 20 个接口，现在 10 分钟就能让 Burp 被动扫描器覆盖全部路径。工具的价值不在多炫酷，而在省下你反复点击的那几百次鼠标——希望帮到你。
本文还有配套的精品资源，点击获取
