前阵子帮一个电商项目做安全整改，漏洞清单里出现频率最高的一项，不是SQL注入也不是越权，而是Cross-Frame Scripting（跨框架脚本，简称XFS）。这类问题在渗透测试报告里经常被写成“可被第三方页面嵌入”或“存在点击劫持风险”，很多人扫出来之后不知道从哪下手：改一个响应头试试？加了X-Frame-Options好像也没什么变化？这篇记录一下我这次处理XFS的完整思路——从复现、定位到CSP frame-ancestors和X-Frame-Options双保险落地，再到业务侧兼容。如果你手里正好有个系统被扫出了这类问题，这篇应该能帮你少花半天时间踩坑。
1. 先想清楚Cross-Frame Scripting到底在攻什么
1.1 同源策略限制的是“读取”，不是“被嵌入”
很多刚接触XFS的同学会有一个疑问：浏览器的同源策略不是已经把跨域请求都拦住了吗，为什么页面还能被第三方用iframe嵌进去干坏事？
这里要掰开讲一下同源策略的真实边界。同源策略管的是脚本对另一个源的DOM读取、Cookie读取这些“读”的能力，它并不禁止A页面把B页面放在iframe里展示出来。也就是说，恶意页面可以把你的登录页、订单页、后台操作页当成一张图片一样“贴”在它自己的页面里，虽然它读不到里面的数据，但用户能看到、能点击。
这就像有人把银行的取款机搬到了自己店里，虽然他没有钥匙打开钱箱，但只要用户走进来按“确认转账”，钱一样会从用户账户里被划走。XFS利用的从来不是读取能力，而是“展示+交互”这个入口——让用户在不知情的前提下，替攻击者完成了操作。
1.2 一个30行的PoC，看懂点击劫持链路
我建议你在测试环境里先写一个最小PoC，亲眼看看效果，比看十篇原理文章都管用。核心思路是这样的：
<!DOCTYPE html> <html> <head> <title>XFS PoC</title> <style> .overlay { position: absolute; top: 0; left: 0; opacity: 0; z-index: 2; } iframe { width: 600px; height: 400px; } </style> </head> <body> <iframe class="overlay" src="https://target.example/user/delete" sandbox=""></iframe> <button style="position: relative; z-index: 1; margin-top: 80px;"> 点击领取优惠券 </button> </body> </html>把iframe的opacity设为0，叠在按钮上方。用户以为自己点的是“领取优惠券”，实际点中的是透明iframe里“删除账号”按钮。如果这个页面对应的处理逻辑没做二次确认，攻击瞬间就完成了。
我第一次把这种逻辑跑通的时候也很感慨：看起来简单得像个笑话，但渗透测试报告里那些“高危”条目，很多就是这种简单手段打出来的。它能影响的场景包括：登录框钓鱼、订单状态篡改、后台审核误操作、第三方登录授权页被嵌。
1.3 影响范围评估：这些页面最容易被盯上
不是所有页面都需要防，优先级要先分清楚。我习惯把页面分成三类：
- 绝对禁止被嵌入：登录页、找回密码页、账号设置页、用户资料页、订单操作页、退款页、管理后台全部操作页、导入导出页。
- 必须允许第三方嵌入：支付回跳页、客服聊天窗口、分享落地页、内容预览页。
- 可以限制性开放：低风险公告页、文章详情页、帮助中心。
判断标准很简单：页面里只要存在一个“能对数据产生写操作”的按钮，就默认禁止嵌入。支付回跳这类场景属于业务刚需，可以放开，但要在放开的路径上做降权处理，后面第4章会说。
2. 三步定位可被嵌入的页面
2.1 全站响应头扫描，别用肉眼翻页面
排查的第一步，是搞一张全站URL清单，然后批量看每个URL返回的响应头里有没有X-Frame-Options和Content-Security-Policy。很多老项目页面特别多，靠人工翻肯定不行，写个小脚本就行。
for url in $(cat urls.txt); do echo "== $url" curl -sI "$url" | grep -iE "x-frame-options|content-security-policy" || echo " 缺Header" done更完整的做法是用Python把所有页面都扫一遍，包括GET和POST接口，重点看HTML页面，因为XFS的入口基本都是页面而不是API。扫出来的“缺Header”页面，再结合业务去判断风险等级。
我提醒一句：响应头可能不止一层来源。有些项目前端Nginx有一层，网关有一层，后端框架又加了一层。扫描时发现“没有Header”不一定是真没有，可能是这一层没有，但更底层有；反过来，某一层加了Header也可能被上层覆盖。所以扫描结果只用来圈范围，最终以浏览器实测为准。
2.2 浏览器控制台会直接告诉你答案
定位阶段最快乐的时刻，是把页面塞进自己的iframe里看报错。在任意一个空白测试页面里写：
<iframe src="https://target.example/user/delete" width="800" height="600"></iframe>如果页面不受保护，iframe能正常加载，那漏洞实锤；如果浏览器弹了类似“拒绝连接”的提示，说明至少有一层保护生效了。这种报错信息在现代浏览器里非常直白，会直接标注“因为设置了X-Frame-Options相关的头策略”。
这里有个小坑：有些页面自己写了frame busting脚本，强行检测自己被嵌入就跳转。这类页面在iframe里加载时会表现为“瞬间跳走”，也会挡掉部分PoC。但frame busting脚本可以被多种方式绕过，不能把它当作安全措施，后面第5章会讲。
2.3 整理业务开放白名单，而不是“一禁了之”
把扫描结果和业务需求放在一起，逐条确认这个页面为什么需要被嵌入，来源域名是谁，有没有备案，是不是合作方。我在这次整改里整理了一张清单：
| 页面 | 现状 | 处理方式 |
|---|---|---|
| 运营后台所有操作页 | 可被任意iframe嵌入 | 全部禁止 |
| 用户订单删除页 | 可被任意iframe嵌入 | 全部禁止 |
| 支付平台回跳页 | 必须被支付平台嵌入 | 按来源域名白名单开放 |
| 客服会话弹窗 | 需嵌入到用户中心 | 同源开放 |
| 活动落地页 | 需嵌入外部媒体 | 临时开放并持续监控 |
业务侧经常有一个误区，觉得“第三方要嵌我们的页面，就给它开个白名单域名就行”。实际上开白名单之前，至少要确认三件事：这个来源域名是不是合作方真实域名、是不是HTTPS、有没有可能被同一个注册主体注册出相似域名来钓鱼。白名单一旦开出去，就要定期回查。
3. 核心修复：CSP和X-Frame-Options怎么配
3.1 为什么两个响应头都要上
X-Frame-Options和CSP的frame-ancestors指令都能限制被嵌入，但能力不一样。这里我直接用对比表说明：
| 维度 | X-Frame-Options | CSP frame-ancestors |
|---|---|---|
| 支持力度 | 老浏览器支持好，新浏览器也认 | 现代浏览器支持好，老内核不认 |
| 可设值 | DENY / SAMEORIGIN 两级 | 支持'none'、'self'、多域名白名单 |
| 多来源白名单 | 不支持，ALLOW-FROM已废弃 | 原生支持 |
| 与业务路径结合 | 只能全站或全目录 | 可按路径细化 |
| 优先级 | 现代浏览器里被CSP覆盖 | 存在时优先于XFO |
最稳的做法是两层同时下发：现代浏览器读CSP的frame-ancestors，老内核浏览器不认识CSP时退回X-Frame-Options。很多只改一个头的项目，要么在旧浏览器上裸奔，要么在新浏览器上策略粒度不够，后面还得返工。
要特别提醒一点：frame-ancestors指令只能出现在HTTP响应头里，写在HTML的meta标签里是无效的。我遇到过有人在页面里加<meta http-equiv="Content-Security-Policy" content="frame-ancestors 'self'">，然后怎么测都还是能嵌，就是这个原因。
3.2 Nginx落地配置与add_header的继承坑
线上大多是Nginx这类反向代理在前面，配置响应头最方便。我这次的标准配置是这样：
server { listen 443 ssl; server_name target.example; add_header X-Frame-Options "SAMEORIGIN" always; add_header Content-Security-Policy "frame-ancestors 'self'" always; }这里的always参数很容易被忽略。不加always时，Nginx只在少数状态码上输出add_header，错误页（404、500等）不会有这些HTTP头。等于攻击者拿一个不存在的路径诱导用户，错误页照样能被iframe嵌进去。加上always之后所有状态码都会带。
还有一个更隐蔽的坑：如果某个location块里自己写了add_header，它会覆盖掉外层server里定义的所有add_header，而不是追加。所以open白名单的路径经常会出现“为什么只配了CSP，XFO不见了”的诡异现象。解决办法是在所有需要单独加头的location里，把公共头再重复写一遍，或者统一提到网关层。
如果确实有业务路径需要允许第三方来源嵌入，可以单独开一个location：
location /pay/return/ { add_header X-Frame-Options "SAMEORIGIN" always; add_header Content-Security-Policy "frame-ancestors https://pay-gateway.example" always; proxy_pass http://backend; }注意这里白名单只写支付网关的域名，不要顺手写个通配符或者*。一旦放开frame-ancestors *，这个页面就回到完全裸奔状态。
3.3 网关统一加头，是避免遗漏的唯一解
如果项目有几十个服务、上百个路由，每个应用都自己配一遍很容易漏。这次整改我选择在统一网关层先兜底，规则是这样的：
- 全局默认：
X-Frame-Options: SAMEORIGIN+frame-ancestors 'self' - 白名单路径：单独在路由规则上覆盖CSP
- 管理后台域名：统一改成
DENY，不允许同源之外任何来源嵌入
这样做的收益是，新服务上线时哪怕后端忘了配安全头，网关也会拦住，不会一夜之间又开出一个新口子。存量老系统里那些不方便改代码的页面，也可以靠网关这层先顶上。
4. 纵深防御：响应头之外还能堵什么
4.1 Cookie的SameSite属性，容易被忽视的助攻
很多人以为XFS只靠响应头就能解决，其实Cookie属性也会影响攻击效果。当恶意页面用iframe加载你的业务页面时，如果Cookie没有设置SameSite，那么跨站请求依然会带上用户登录态，攻击者诱导用户点一下“删除”，请求照样能用合法身份发出。
把关键业务域的Cookie设置成SameSite=Lax或者SameSite=Strict之后，跨站iframe里发出去的请求就不会自动带Cookie。这就等于即使攻击者把页面嵌进来了，也很难利用用户登录态完成敏感操作。
这里有一个不能混淆的点：SameSite解决的是“跨站请求带不带身份”的问题，它不解决“页面能不能被嵌入”的问题。所以它是加法，不是替代。响应头仍然是主防线，SameSite是第二道。
4.2 必须开放白名单的页面，做降权处理
支付回跳、客服弹窗这类业务刚需页面，确实没法一禁了之。我的经验是：能开放，但要把页面功能降到最低。
比如客服会话弹窗，被嵌到用户中心时只允许加载聊天记录和消息输入框，不允许在弹窗内执行删除工单、拉黑用户、导出会话记录等管理操作。具体做法是在后端接口层再做一次来源校验，判断Referer或专门的下发标识。如果请求不是从合作方的可信域名发起的，敏感接口直接返回403。
支付回跳页也是同理。页面可以允许被支付平台嵌入，但页面内不要放任何“再次支付”“重新下单”之外的可操作按钮，尤其不要把“修改支付方式”这种涉及账号资产的入口放在回跳页上。
4.3 用Report-Only模式，先观察再强制
大范围改安全策略，最怕的是某个白名单域名漏配，导致业务链接全部打不开。安全整改其实可以不“一刀切”，先用CSS和CSP的报告模式跑一段时间。
add_header Content-Security-Policy-Report-Only "frame-ancestors 'self'; report-uri https://csp-collector.example/report" always;这个头不会阻止任何页面被嵌入，但浏览器会把所有“如果强制启用就会被拦截”的情况上报到指定地址。收集到报告之后，看看里面出现的来源域名有哪些，再决定哪些进白名单、哪些进黑名单。观察一周没有异常，再把Report-Only换成强制执行的CSP。
我这次就是先把所有页面都切换成Report-Only跑了两天，发现有两家以前合作过的第三方域名还在嵌我们的活动页，其中一家早就停止合作了，顺手把它从白名单里清了。这个过程不动业务，排查效率很高。
5. 常见坑与排查技巧速查
5.1 高频问题速查表
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 加了Header但抓包看不到 | add_header在子location里被覆盖，或没加always | 检查全局配置，把公共头提到外层或重复声明 |
| 响应头有，但页面还是能嵌 | frame-ancestors写进了meta标签 | 改为HTTP响应头下发 |
| 老内核浏览器里会话页能被嵌入 | 老内核不识别CSP frame-ancestors | 强制保留X-Frame-Options兜底 |
| 404、500错误页没有安全头 | add_header未加always | 统一加always，错误页单独验证 |
| 配置了CSP但只写default-src | frame-ancestors是独立指令，不能混进default-src | 单独写frame-ancestors |
| 页面在办公IM里无法预览 | 办公协作软件用iframe预览链接，被DENY拦截 | 对预览来源域名做白名单，或提供纯文本摘要页 |
| 白名单域名的子域仿冒 | 只精确到主域名，攻击者注册相似子域 | 白名单精确到完整域名，不加通配符 |
| frame busting脚本跳转失效 | 攻击者用sandbox属性禁掉top导航 | 不要依赖JS脚本，以响应头为准 |
5.2 两个容易忽略的细节
第一个细节是优先级。现代浏览器里如果同时存在CSP frame-ancestors和X-Frame-Options，会优先看CSP；而老内核浏览器不认识CSP时才会看XFO。这意味着两个头的配置不能“打架”，不能一个说SAMEORIGIN一个说'none'。我在一个项目里见过XFO配了DENY、CSP却配了frame-ancestors *，结果所有历史版本浏览器同时崩溃——一部分被DENY挡住，一部分被通配符放行，测试结论完全相反。
第二个细节是跳转链路上的Header丢失。很多系统有302 → 目标页的跳转，如果只检查了最终响应页的安全头，忽略了302中间响应的头，某些场景下攻击者可以拿中间URL直接诱导用户。排查时建议连302、301响应的Header一起看，凡是HTML页面能经由的状态码都要覆盖。
还有一个我踩过多次的坑：改完安全头之后，一定要用真实浏览器重测一遍，而不是只看curl结果。curl能看到响应头里有CSP，但浏览器是否解析成功、是否被浏览器扩展干扰、是否命中缓存，这些只有实际打开页面才能确认。测的时候记得开无痕窗口，避免本地缓存拿到旧响应头。
改完这些之后，我又花了半天把线上链接统一复查了一遍，确认所有管理后台和用户操作页都返回了frame-ancestors 'self'，白名单页面返回了具体合作方域名。安全整改最容易被忽视的其实是“后续维护”，新页面上线时如果不检查安全头，过两个月又会出现一个可以被嵌入的入口。我的习惯是把它加进发布检查清单，每次上线前自动跑一次响应头扫描，有问题直接在发布流程里拦下来。XFS修复本身不难，难的是让这套保护成为项目默认配置，而不是出了漏洞才想起来补。
