简介本资源是面向网络安全从业者与渗透测试初学者的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 不等于伪造源 IPSource 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.10.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 flask2.3.3该项目无其他第三方依赖requirements.txt仅含 Flask版本锁定为 2.3.3 是因高版本 Flask 对request.headers的 mutable 属性处理有变更会导致 Host 替换失败。若你环境已装有 Flask建议先卸载再重装指定版本pip uninstall flask -y pip install flask2.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 8081BurpFakeIP 自身监听端口浏览器需配置为此端口若 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 CTRLC to quit3.3 浏览器代理配置与 Burp 设置联动确保 Passive Scan 生效浏览器设置代理为127.0.0.1:8081而非直接设为 Burp 的8080Burp 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 ServerBurpFakeIP 在转发前将Host: example.com替换为Host: 127.0.0.1Burp 收到的请求头已是 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 WorkerChrome 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?urlhttps://$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.1Host,X-Forwarded-HostContent-Type: application/json{status:UP}或!DOCTYPE html内网页面AWS Metadata 暴露169.254.169.254HostContent-Length: 1000ami-id、instance-id字符串Docker Remote API127.0.0.1:2375HostContent-Type: application/jsonContainers数组Kubernetes API10.96.0.1:443Host,Authorization需提前注入 Tokenkind: 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-26134Confluence 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 已帮你把整个浏览过程转化为Host127.0.0.1的批量探测。5.3 WAF 绕过实战用 Fake IP 触发不同规则集很多 WAF如 Cloudflare、ModSecurity对Host: 127.0.0.1的请求启用更宽松的规则因为它们默认认为“本地请求可信”。BurpFakeIP 可用来对比测试WAF 类型原始 Host 响应Fake IP Host 响应判定依据Cloudflare403 Forbidden规则 ID 1001200 OK 正常 HTML查看响应状态码及cf-rayHeader 是否变化ModSecurity (OWASP CRS)403X-CRS-Action: BLOCKED200X-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 被动扫描器覆盖全部路径。工具的价值不在多炫酷而在省下你反复点击的那几百次鼠标——希望帮到你。本文还有配套的精品资源点击获取