【Web安全】iframe注入漏洞从入门到实战

⚠️本博文所涉安全渗透测试技术、方法及案例，仅用于网络安全技术研究与合规性交流，旨在提升读者的安全防护意识与技术能力。任何个人或组织在使用相关内容前，必须获得目标网络 / 系统所有者的明确且书面授权，严禁用于未经授权的网络探测、漏洞利用、数据获取等非法行为。

1. 漏洞背景与核心定义

1.1 漏洞本质与所属分类

iframe注入是跨站脚本攻击（XSS）的典型变体，也是Web安全中高频出现的漏洞类型，其本质是后端未对用户可控内容做过滤/编码，导致恶意<iframe>标签被拼接进页面并被浏览器解析执行，属于后端代码层面的漏洞，前端仅能做辅助防御，无法从根源解决。

该漏洞的核心危害是让攻击者能在目标网站中嵌入恶意页面，实现钓鱼、窃取用户Cookie、植入木马、劫持用户操作等恶意行为。

1.2 常见攻击场景

iframe注入的攻击场景均围绕用户可控内容展开，常见的触发场景有：

• 异常页面直接拼接请求URL、异常信息到页面；
• 留言板、评论区等用户输入模块未做过滤，直接渲染用户提交内容；
• 搜索结果页、个人资料页将用户输入的参数直接输出到HTML中；
• 数据库中存储的恶意内容被后端直接读取并渲染到页面。

2. 漏洞原理与实战案例

2.1 核心触发原理

1. <iframe>标签是HTML的内联框架标签，浏览器解析到该标签时，会自动加载并渲染其src属性指向的页面；
2. 攻击者构造包含恶意<iframe>标签的内容，通过用户可控入口传入后端；
3. 后端未对该内容做HTML编码，直接将其拼接进页面HTML代码中并返回给浏览器；
4. 浏览器将拼接后的恶意<iframe>标签当作正常HTML解析执行，加载恶意页面，完成注入攻击。

简单来说：后端把用户写的恶意代码，当成了页面的正常HTML输出，浏览器照单执行。

2.2 漏洞案例

参考案例

以下是项目中出现的存在iframe注入漏洞的ASP.NET全局异常处理代码，也是触发iframe注入的典型场景：

voidApplication_Error(objectsender,EventArgse){// 未处理的全局异常逻辑ExceptionobjErr=Server.GetLastError().GetBaseException();// 直接拼接用户可控的Request.Url和异常信息，无任何过滤编码stringerror="<br/><br/><span style='color:Red'>发生异常页：</span>"+Request.Url.ToString()+"<br/><br/>";error+="<span style='color:Red'>异常信息：</span>"+objErr.Message+"<br/><br/>";Server.ClearError();Application["error"]=error;// 跳转到错误页渲染拼接后的内容Response.Redirect("error.aspx");}

漏洞核心点：Request.Url.ToString()是用户完全可控的内容，后端直接将其拼接进HTML字符串，并存入Application["error"]后在error.aspx中渲染，为iframe注入提供了直接入口。

2.3 完整攻击流程还原

以上述ASP.NET漏洞代码为例，还原攻击者实现iframe注入的完整步骤：

1. 构造恶意请求URL：攻击者在目标网站的URL中嵌入恶意<iframe>标签，示例：
   http://目标网站.com/?test='><iframe src=//恶意钓鱼网站.com width=100% height=100%></iframe>
2. 触发后端异常：攻击者通过构造非法参数，让目标网站触发后端未处理异常，进入Application_Error逻辑；
3. 后端拼接恶意内容：后端执行Request.Url.ToString()获取到包含恶意<iframe>的URL，并将其拼接进error字符串，最终Application["error"]中存储的是包含恶意iframe的HTML代码；
4. 浏览器解析执行：页面跳转到error.aspx后，渲染Application["error"]中的内容，浏览器解析到<iframe>标签后，自动加载src指向的恶意钓鱼网站；
5. 实现攻击目的：访问该页面的用户会在目标网站中看到恶意钓鱼页面，攻击者可借此窃取用户的账号、密码、Cookie等敏感信息。

3. 漏洞测试方法

3.1 手工测试步骤

iframe注入的手工测试核心是找到用户可控内容的输出点，构造恶意iframe标签验证是否被执行，通用测试步骤如下：

1. 寻找输出点：定位网站中用户输入参数、请求URL、异常信息等用户可控内容直接输出的页面（如搜索页、错误页、评论页）；
2. 构造测试payload：在可控参数后拼接简易的iframe测试代码，示例：
   ?param=<iframe src=//baidu.com width=200 height=200></iframe>
3. 访问并验证：访问构造后的URL，查看页面是否出现百度的内嵌页面；若出现，则说明存在iframe注入漏洞；若仅显示纯文本的iframe代码，则说明后端做了编码过滤，无漏洞；
4. 验证高危payload：若简易payload生效，可进一步构造钓鱼、窃取Cookie的恶意payload，验证漏洞的实际危害。

3.2 测试核心要点

• 测试时优先选择异常页面、搜索结果页，这类页面是iframe注入的高发区域；
• 若直接拼接payload被WAF拦截，可尝试简单的变形（如大小写混合<IfRaMe>），验证过滤规则的严格性；
• 验证时需注意页面是否有JS、CSS对iframe做隐藏，可通过审查元素查看页面源码中是否存在注入的iframe标签。

4. 漏洞审计技巧

4.1 后端代码审计重点

iframe注入的代码审计核心是查找「用户可控内容直接拼接进HTML并输出」的代码逻辑，审计时重点关注以下几点：

1. 用户可控变量：所有来自前端的参数均为可控内容，如Request.Url、Request.QueryString、Request.Form、异常信息ex.Message等；
2. 字符串拼接操作：查看后端是否将可控变量直接与HTML标签拼接成字符串；
3. 页面输出方式：拼接后的字符串是否被存入全局变量（如ASP.NET的Application、Session）、直接渲染到页面，或通过接口返回给前端并渲染；
4. 编码过滤逻辑：可控变量在拼接/输出前，是否调用了HTML编码函数（如ASP.NET的HttpUtility.HtmlEncode、Java的org.apache.commons.lang3.StringEscapeUtils.escapeHtml4）。

4.2 易出问题的代码场景

审计时重点检查以下高频出现漏洞的代码场景，几乎90%的iframe注入都出现在这些场景中：

• 全局异常处理逻辑（如ASP.NET的Application_Error、Java的全局异常拦截器）；
• 无模板引擎的原生页面渲染（直接拼接HTML字符串）；
• 留言、评论、私信等用户输入模块的提交与渲染逻辑；
• 搜索结果、关键词展示等直接输出用户输入参数的页面；
• 后台管理系统的日志展示页（若日志中包含用户可控内容，且直接渲染）。

5. 漏洞防御方案

5.1 核心根治方案：后端强制HTML编码

这是解决iframe注入最根本、最有效的方法，原理是将HTML中的特殊字符（<、>、'、"、&）转义为HTML实体，让浏览器将其当作纯文本显示，而非解析为HTML标签。

修复示例

对上述漏洞代码进行修复，调用HttpUtility.HtmlEncode对所有用户可控内容做编码：

voidApplication_Error(objectsender,EventArgse){ExceptionobjErr=Server.GetLastError().GetBaseException();// 核心：对用户可控内容做HTML编码stringerrPage=HttpUtility.HtmlEncode(Request.Url.ToString());stringerrMsg=HttpUtility.HtmlEncode(objErr.Message);// 拼接编码后的内容stringerror="<br/><br/><span style='color:Red'>发生异常页：</span>"+errPage+"<br/><br/>";error+="<span style='color:Red'>异常信息：</span>"+errMsg+"<br/><br/>";Server.ClearError();Application["error"]=error;Response.Redirect("error.aspx");}

编码后效果：恶意<iframe>标签会被转义为<iframe src=//恶意网站.com></iframe>，浏览器仅会显示纯文本，不会执行。

各语言核心编码函数

• ASP.NET：HttpUtility.HtmlEncode(string)
• Java：org.apache.commons.lang3.StringEscapeUtils.escapeHtml4(String)、javax.servlet.jsp.JstlCore.fn:escapeXml(String)
• PHP：htmlspecialchars(string, ENT_QUOTES, 'UTF-8')
• Python：html.escape(string)

5.2 前端辅助防御

前端防御无法根治漏洞，仅能作为二次防护，拦截漏网的恶意iframe，适合作为后端编码的补充：

1. CSS拦截（仅兼容老式IE，应急使用）：通过IE专属的expression特性销毁页面中的iframe，应急止损时使用（适合网站被批量挂马的场景），代码如下：

   <style type="text/css"> iframe{v:expression(this.src='about:blank',this.outerHTML='');}</style>

   若自身网站需要使用合法iframe，可通过ID做白名单：#legalIframe{v:expression() !important}；

2. JS监控DOM：监听页面DOM变化，发现非白名单的iframe标签时，立即移除并置空src：

   // 简易示例：移除所有iframe，可根据业务添加白名单判断setInterval(()=>{document.querySelectorAll('iframe').forEach(iframe=>{iframe.src='about:blank';iframe.remove();});},100);

3. CSP内容安全策略：通过设置CSP响应头，限制页面可加载的iframe域名，仅允许合法域名的iframe，示例：
   Content-Security-Policy: frame-src 'self' https://合法域名.com;
   该配置会阻止页面加载任何非白名单域名的iframe，即使出现注入，也无法加载恶意页面。

5.3 配置层面加固

1. 配置X-Frame-Options响应头：禁止网站被其他域名通过iframe嵌入，同时也可限制自身页面的iframe加载规则，常用配置：
   • X-Frame-Options: DENY：禁止任何域名嵌入当前网站的页面；
   • X-Frame-Options: SAMEORIGIN：仅允许同域名嵌入；
   • 配置示例（Nginx）：add_header X-Frame-Options "SAMEORIGIN";
2. WAF规则拦截：在Web应用防火墙（WAF）中配置规则，拦截包含<iframe>、<script>等恶意标签的请求，作为漏洞的前置拦截；
3. 统一页面渲染规范：项目中使用模板引擎（如Vue、React、Thymeleaf、Razor），模板引擎会自动对变量做HTML编码，避免手动拼接HTML字符串带来的漏洞。

6. 总结

iframe注入作为XSS的典型变体，本质是后端未对用户可控内容做HTML编码，导致恶意标签被浏览器解析执行，其核心危害是让攻击者能在目标网站中嵌入恶意页面，实现钓鱼、信息窃取等行为。

该漏洞的测试和审计均围绕用户可控内容的输出与过滤展开，手工测试的核心是构造恶意iframe payload验证是否被执行，代码审计的核心是查找未做编码的可控内容拼接逻辑。

防御的关键是后端对所有用户可控内容强制做HTML编码，这是从根源上解决漏洞的唯一方法；前端的JS/CSS拦截、CSP配置，以及服务端的X-Frame-Options头、WAF规则，均为辅助防御手段，可进一步提升漏洞防御的安全性。

本文是「Web安全基础」系列内容，点击专栏导航查看全部系列内容。