# 反射型 XSS(get)
# 过程
- 在输入框中输入任意字段,查看页面代码可以发现输入字段已经被插入到了页面之中
- 这里可以尝试直接输入相应的 XSS payload,如
<script>alert(1)</script>
<details+open+ontoggle=prompt(1)>
<svg/onload=confirm(1)>
等
- 输入的时候可以发现输入框有输入字符的上限(并且该输入框在测试时还可以发现其对输入字符髌骨无限制,特殊字符如 / 等可以直接插入到前端代码中),但这些不算很重要,我们可以直接在前端的代码上修改,也可以在网页的 url 上根据规律进行插入
- 反弹结果
# 总结
GET 方式要更容易被利用,因为相关元素可以直接通过网页 URL 直接提交,通常的利用形式为将带有跨站脚本的 URL 伪装后发送给目标
# 反射型 XSS(post)
# 过程
- 由于使用的是 post 方法,这里需要使用 burp suite 进行数据包的抓取
- 根据重放可知字符也已经插入页面代码
- 修改抓取的数据包,将 message 修改为 XSS 的 payload
- 放行后输出结果,可以看到 payload 已经插入页面代码中
# 总结
POST 方式相对 GET 要更难被利用,但这同样存在安全隐患,这里就通过对数据包的篡改完成了 XSS 的 payload 插入,主要的利用方式会在 XSS 之盲打中会介绍
# 存储型 XSS
# 过程
- 首先同样输入任意值,测试其是否存在对特殊字符的过滤
- 直接输入 XSS 的 payload,反弹结果,同时可以查看页面代码,发现 payload 已经被插入其中
# 总结
存储型 XSS 在道理上和反射型差不多,区别在于存储型会被存储起来,而反射型则是一次性的
# DOM 型 XSS
# 过程
- 同样首先输入任意字符,查看页面元素可知字符已被插入到前端中
- 输入 payload:
javascript:alert(1)
尝试触发漏洞,查看页面元素可知 payload 已被插入到前端,点击what do you see?
可以看到漏洞已触发
# 总结
这类型漏洞危害性不算非常大,但依旧需要留意
# DOM 型 XSS-X
# 过程
- 与上一个关卡相同,先输入任意值,在页面元素中查看相关信息
- 然后输入 payload 尝试触发漏洞,随后查看 payload 是否已经插入至页面元素中
# 总结
这类型漏洞在某些方面与反射型 XSS 类似,它们同样都是通过 url 来获取输入,实际上在观察 url 内容后就可以发现 url 中有我们先前的输入 javascript%3Aalert(1)
,其中 :
在 url 内表现为 %3A
,这些符号都有固定的翻译对应,例如空格就会翻译为 %20
。
# XSS 之盲打
# 过程
- 老规矩,先输入任意值,在前端代码中并没有看到相应的输出,所以这里需要登录管理后台查看结果
- 随后输入 payload
<script>alert(1)</script>
尝试触发漏洞,由于前端并没有对应代码显示,所以需要到后台查看漏洞是否被触发。可以看到弹窗,漏洞已经被触发。
# 总结
盲打主要指的是这么一种攻击场景,前端输入的内容只有在后端才能看到,这类型的攻击通常具有随机性,首先输入框有可能存在对特殊字符和语句的过滤,导致跨站脚本上传失败,即使能够上传成功,在后端也有可能有过滤或验证,导致脚本不一定会被触发。但是危害同样很大,如果不存在上述验证,那么完全可以将脚本替换为获取 cookie 的脚本,如果管理员登陆就有可能会被盗取 cookie,导致管理权限的外泄。
# XSS 过滤
# 过程
-
依旧是老规矩,首先随意输入查看过滤情况,可以发现如
<script>
或双写关键词<scrscriptipt>
等都被过滤掉了 -
尝试修改 payload 格式,发现大写形式是不会被过滤的,写入后成功触发漏洞
# 总结
这里漏洞的问题还是在于过滤的规则不够完善,查看源代码可以发现,实际上是只对 <script
进行了过滤,简单点的绕过可以通过改变大小写来实现,同时也可以使用其他 payload 如 img 的标签 <img src=x onerror="alert(1)">
来实现绕过
# XSS 之 htmlspecialchars
# 过程
- 仍旧老规矩,随意输入字符,查看是否插入至前端中
- 根据 htmlspecialchars 方法默认不对
'
进行处理的特点,我们可以构造 payload1' oneclick='alert(1)'
,输入后查看结果
# 总结
htmlspecialchars () 函数功能为把预定的字符转换为 HTML 实体,当前预定义的字符有:
& → &
" → "
' → &apos
< → <
> → >
# XSS 之 href 输出
# 过程
- 随意输入字符,查看页面源代码插入位置
- 此处可以直接构造 payload
javascript:alert(1)
,输入后查看结果
# 总结
这个漏洞比较简单,此处我们可以只允许 http、https,其次再进行 htmlspecialchars 处理
# XSS 之 js 输出
# 过程
- 首先随意输入字符,发现代码中使用 $ms 来传递参数
- 构造 payload 尝试闭合掉下方的 if 判断句
1'</script><script>alert(1)</script>
# 总结
这里主要的操作是再输入框后增加前端代码完成对原有代码的闭合,将原来的判断语句直接排除在外,这样就避免了 if 的验证,实现绕过。