目录
![]()
方法一:
直接把20给它改成200
<script>alert(document.cookie)</script>
方法二:

网页框之间输入
因为输入的Payload会在网址框显示,而网址框是没有长度限制的
所以可以之间在网址框插入Payload
- <script>alert("caker")<%2fscript>
- %2f为URL编码中的 /
和1差不多,要先以post方式登入
<script>alert(document.cookie)</script>

存储型XSS漏洞跟反射型形成的原因一样,不同的是存储型XSS下攻击者可以将脚本注入到后台存储起来,构成更加持久的危害,因此存储型XSS也称“永久型”XSS。
页面切换,然后再次切换回来,发现弹窗依然存在,说明我们输入的语句已经被存储起来。
HTML DOM 是关于如何获取、更改、添加或删除 HTML 元素的标准

看起来应该是a标签,打开页面源码,CTRL+F搜索这串字符

利用了DOM将字符串进行了拼接并把值给a标签的href,然后输出一个what do you see?
所以我们可以利用已知条件构建payload效果为弹窗,弹窗内容为XSS
- <a href='#' onclick="alert(xss)">'>what do you see?
故:
#' onclick="alert(xss)">

查看源码

分析代码,利用了DOM将字符串进行了拼接并把值给a标签的href,就是比第4题更容易利用而已
#' οnclick="alert(xss)">
tip:
由于本关payload在url中,因此比第4关好利用很多
DOM型XSS只在前端,与后端毫无关系。DOM-X型危害更大,它能够像反射型一样在URL中体现,将URL发给了受害者就能进行攻击。

输入代码后,页面没有反应

不妨打开后端页面

登录后发现我们之前输入的内容已经记录在后台,而且内容和用户名都有显示,所以对两个输入框都进行测试
Payload:

这种情况就是xss盲打,对攻击者来说只是尝试的输入,并不知道后台是否被输出,只是尝试的输入跨站脚本。管理员被x到,攻击者成功。这种危害比较大,如果在前端输入一段盗取cookie的脚本,管理员一登陆,管理员的cookie就会被获取。攻击者就可以伪装管理员登陆后台,后台的权限就大了。
XSS绕过-过滤-转换;
- 大小写,比如:
- 前端限制绕过,直接抓包重放,或者修改html前端代码
- 拼凑:
pt> alert(111) pt>- 使用注释进行干扰:
pt> alert(111) ript>
先输入,试试

好家伙, 全被过滤掉了。

输入所有可能的敏感字母:"<>'on/`() script href src img

可以把这些一个个输入提交试试,如果单独输入"<>‘on/’()则什么都没有被过滤,如果输入了"<>‘on/’() script img href src,则<>‘on/’() script被删掉了,这说明过滤语句超可能是<.*script
<a herf="#" onclick="alert(document.cookie)">
<img src=x onerror="alert(666)">
htmlspecialchars()函数把预定义的字符转换为HTML实体
- & (和号)成为 &
- " (双引号)成为 "
- ' (单引号)成为 '
- < (小于)成为 <
- > (大于)成为 >
我们输入:jinyouxin' "<>#$% have a try

除了单引号其他的特殊字符都进行了编码,我们可以输入#' οnclick='alert(document.cookie)'
第一个单引号是对前面进行闭合。

先用 jinyouxin' "<>#$% 试试

补充:
href 属性的值可以是任何有效文档的相对或绝对 URL,包括片段标识符和 JavaScript 代码段。如果用户选择了
标签中的内容,那么浏览器会尝试检索并显示 href 属性指定的 URL 所表示的文档,或者执行 JavaScript 表达式、方法和函数的列表。
敏感字母都被编码了,可以使用JS伪协议绕过:
javascript:alert(document.cookie)

思考:
那么当用户输入由href属性输出时,该怎么防御xss呢?
仅仅html编码就不够了,本关的php源代码中给了提示(有点简略,这里稍微扩充一点)。遇到这种情况,需要两点处理:
- 检查用户输入,必须以http或者https开头。注意,不可以仅仅是包含http和https。
- 进行html实体编码
先用 jinyouxin' "<>#$% 试试

直接在中,这样就容易了,payload:';alert(/xss/);//
