正文

XSS新攻击的深入剖析：新场景利用与系统化防御策略

admin
admin V管理员 /0 评论 /25 阅读
0326
此篇文章发布距今已超过2天，您需要注意文章的内容或图片是否可用！

免责声明：由于传播、利用本公众号所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，公众号及作者不为此承担任何责任，一旦造成后果请自行承担！如有侵权烦请告知，我们会立即删除并致歉。谢谢！

文章作者：先知社区(1398133550745333)

文章来源：https://xz.aliyun.com/news/17227

前言

xss挖掘难道还停留在分三种基础类型？其实xss还有更多的隐藏在其他场景中的，这些一般都是容易忽略的，下面详细分析分析，从代码层面也会讲解漏洞原因，还有目前xss的各种修复手法

其他常见的场景

模板渲染

有去看过一些 cms，确实是这样的，比如模板的特殊标签

th:text 用于展示纯文本，会对特殊字符进行转义
th:utext 则不进行转义，直接展示原始HTML内容
当获取后端传来的参数中带有HTML标签时，th:text不会解析这些标签，而th:utext会解析并渲染它们。这类似于Vue中的v-text和v-html

public String handleTemplateInjection(String content,Stringtype, Model model) {    if ("html".equals(type)) {        model.addAttribute("html", content);    } else if ("text".equals(type)) {        model.addAttribute("text", content);    }    return "vul/xss/other";}<div class="layui-card-body layui-text layadmin-text" style="color: red;font-size: 15px;">        <pth:utext="${html}"></p>        <pth:text="${text}"></p></div>

这个规范一下就 ok 了

文件上传 xss

SRC中经常遇到的就是 svg ，html，xml，pdf没有危害就不管了

我们只需要关注一下文件应该怎么写，这个才是重点

html 就很简单,就是插入我们的脚本就 ok

<!DOCTYPE html><htmllang="en"><head>    <metacharset="UTF-8">    <title>HTML类型</title></head><body>  <h1>可上传HTML类型文件导致XSS!</h1>  <script>alert(document.cookie)</script></body></html>

svg

<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE svgPUBLIC"-//W3C//DTD SVG 1.1//EN""http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"><svgversion="1.1"id="Layer_1"xmlns="http://www.w3.org/2000/svg"xmlns:xlink="http://www.w3.org/1999/xlink"x="0px"y="0px"width="100px"height="100px"viewBox="0 0 751 751"enable-background="new 0 0 751 751"xml:space="preserve">  <imageid="image0"width="751"height="751"x="0"y="0"    href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAu8AAALvCAIAAABa4bwGAAAAIGNIUk0AAHomAACAhAAA+gAAAIDo" />    <script>alert(document.cookie)</script></svg>

svg 可以 xss 的原因就是因为可以解析 script 标签

xml

<data>    <message>This is a &lt;script&gt;alert('XSS')&lt;/script&gt; payload</message></data>

这个比较鸡肋，需要解析 xml 才可以，我觉得最常用的就是 svg 了

组件漏洞

JQuery-XSS 漏洞

<head>  <metacharset="utf-8">  <title>jQuery XSS Examples (CVE-2020-11022/CVE-2020-11023)</title>  <!-- 测试JQuery -->  <scriptsrc="/lib/jquery-1.6.1.js"></script>  <!-- <script src="./jquery.min.js"></script> --></head>

CVE-2020-11022/CVE-2020-11023

CVE-2020-11022 和 CVE-2020-11023 是 jQuery 的两个跨站脚本（XSS） 漏洞，影响 jQuery 1.2 - 3.5.0 版本，主要与html()方法有关。

CVE-2020-11022

影响$().html()方法
允许攻击者通过不受信任的HTML代码执行恶意JavaScript代码
例如：插入script、iframe、onerror等危险标签绕过安全检查

CVE-2020-11023

影响$().html()方法在SVG元素中处理不当，允许攻击者注入恶意 JavaScript，导致XSS

比如

<divid="content"></div><script>    var userInput = '<img src=x onerror=alert("XSS")>';    $("#content").html(userInput); // 🚨 直接插入，存在漏洞</script>

然后下一个 cve 就是绕过

Swagger UI XSS漏洞（CVE-2023-38418）
<!--swagger依赖--><dependency>    <groupId>io.springfox</groupId>    <artifactId>springfox-boot-starter</artifactId>    <version>3.0.0</version>// 该版本存在xss</dependency>

API文档的description、operationId、summary、contact等字段可被插入恶意HTML/JavaScript代码
Swagger UI在渲染这些字段时未对HTML进行适当的转义，比如；

{  "openapi": "3.0.0",  "info": {    "title": "Swagger XSS",    "version": "1.0.0",    "description": "<script>alert('XSS')</script>"  }}

作者使用的就比较复杂了
最后是在远程文件https://jumpy-floor.surge.sh/test.yaml

所以需要等待一会才会弹出

漏洞代码修复

白名单

// 对用户输入的数据进行验证和过滤，确保不包含恶意代码。使用白名单过滤，只允许特定类型的输入，如纯文本或指定格式的数据// 前端校验代码var whitelistRegex = /^[a-zA-Z0-9_s]+$/;// 检查输入值是否符合白名单要求if (!whitelistRegex.test(value)) {    layer.msg('输入内容包含非法字符，请检查输入', {icon: 2, offset: '10px'});    return false; // 取消表单提交    } else {        // 正常发送请求    }// 后端校验代码private static final String WHITELIST_REGEX = "^[a-zA-Z0-9_\s]+$";private static final Pattern pattern = Pattern.compile(WHITELIST_REGEX);Matcher matcher = pattern.matcher(content);if (matcher.matches()){    return R.ok(content);}else return R.error("输入内容包含非法字符，请检查输入");

xss 的本质就是需要各种标签去解析，如果我们不能输入标签，那么就可以阻止xss

我们只能输入字母、数字、下划线和空格

前端

但是我们如果仅仅只是前端过滤的话，任然可以被绕过，这在 src 中很常见

我们输入一个 1 然后抓包

然后再修改我们的 payload

GET /xss/reflect/safe1?content=%3c%73%63%72%69%70%74%3e%61%6c%65%72%74%28%2f%78%73%73%2f%29%3c%2f%73%63%72%69%70%74%3e&type=frontEnd&_=1738825573547 HTTP/1.1Host: 127.0.0.1:9898sec-ch-ua: "Chromium";v="125", "Not.A/Brand";v="24"Accept: */*Content-Type: application/x-www-form-urlencoded;charset=UTF-8X-Requested-With: XMLHttpRequestsec-ch-ua-mobile: ?0User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.6422.112 Safari/537.36sec-ch-ua-platform: "Windows"Sec-Fetch-Site: same-originSec-Fetch-Mode: corsSec-Fetch-Dest: emptyReferer: http://127.0.0.1:9898/xss/reflect/safeAccept-Encoding: gzip, deflate, brAccept-Language: zh-CN,zh;q=0.9Cookie: USER_ID_ANONYMOUS=97269975b0004387b7443950946b97a8; DETECTED_VERSION=5.2.0; MAIN_MENU_COLLAPSE=false; DG_USER_ID_ANONYMOUS=e5dbe5efa486485aa7d6260b97b1fe1d; JSESSIONID=E6B03C38C24E570648FC87997AAB56B4Connection: keep-alive

所以开发的时候我们需要在后端写我们的过滤逻辑

后端

如果过滤在后端，无论我们是抓包还是前端输入，都会被拦截

即使我们使用 bp

<!DOCTYPE html><htmllang="en"><head>    <metacharset="UTF-8">    <title>HTML类型</title></head><body>  <h1>可上传HTML类型文件导致XSS!</h1>  <script>alert(document.cookie)</script></body></html>0

可以看到还是需要进行数据的过滤

CSP 策略

内容安全策略(CSP：Content Security Policy)是一种由浏览器实施的安全机制(可理解为额外的安全层)，旨在减少和防范跨站脚本攻击等安全威胁核心原理：网站通过发送一个 CSP header 头部(也可以在 html 直接设置)，告诉浏览器具体的策略(什么是授权的与什么是被禁止的)，从而防止恶意内容的加载和执行

CSP 指令说明：

  • default-src: 指定默认的加载内容的来源，如果未指定其他指令，则默认应用此指令

  • script-src: 指定允许加载 JavaScript 的来源

  • style-src: 指定允许加载样式表的来源

  • img-src: 指定允许加载图片的来源

  • connect-src: 指定允许向其发送请求的来源(例如 AJAX、WebSocket 连接等)

安全代码

<!DOCTYPE html><htmllang="en"><head>    <metacharset="UTF-8">    <title>HTML类型</title></head><body>  <h1>可上传HTML类型文件导致XSS!</h1>  <script>alert(document.cookie)</script></body></html>1

我们重点关注 csp 的限制

限制所有资源（脚本、样式、图片等）只能来自同源（self），不允许外部来源的资源加载。

然后

可以看见 csp 起作用

特殊字符实体转义

<!DOCTYPE html><htmllang="en"><head>    <metacharset="UTF-8">    <title>HTML类型</title></head><body>  <h1>可上传HTML类型文件导致XSS!</h1>  <script>alert(document.cookie)</script></body></html>2

可以看到把我们的关键 xss 代码转义了

我们尝试输入一段 xss 代码测试

可以看见成功转义了

我们看到代码部分，是会进入 htmlEscape 函数去转义

HttpOnly

如果 Cookie 设置了 HttpOnly，那么前端 JavaScript 无法读取 Cookie，即使攻击者利用 XSS 注入恶意脚本，也无法窃取 Cookie。

配置方法如下

三种

<!DOCTYPE html><htmllang="en"><head>    <metacharset="UTF-8">    <title>HTML类型</title></head><body>  <h1>可上传HTML类型文件导致XSS!</h1>  <script>alert(document.cookie)</script></body></html>3

我们尝试弹一个 cookie

<!DOCTYPE html><htmllang="en"><head>    <metacharset="UTF-8">    <title>HTML类型</title></head><body>  <h1>可上传HTML类型文件导致XSS!</h1>  <script>alert(document.cookie)</script></body></html>4

我们看看能不能窃取我们的 JSESSIONID

可以看到失败了，只能获取我们的

<!DOCTYPE html><htmllang="en"><head>    <metacharset="UTF-8">    <title>HTML类型</title></head><body>  <h1>可上传HTML类型文件导致XSS!</h1>  <script>alert(document.cookie)</script></body></html>5

参考连接：https://github.com/whgojp/JavaSecLab/wiki

 


推荐站内搜索：最好用的开发软件、免费开源系统、渗透测试工具云盘下载、最新渗透测试资料、最新黑客工具下载……
宙飒天下网