写在前面:
仅供学习使用
第六关
照例测试看看有无过滤,可以看出标签没被过滤,只是关键字重组了。



最重要的是发现大小写没被过滤,那么闭合input完事。


第七关
照例弹窗测试,发现关键字被过滤了,大小写也被过滤了,但是标签可以用。看到过滤想到嵌套,试试嵌套。

嵌套发现没问题,那么闭合input完事。

从<script>alert(1)</script>变成<>alert(1)</>,可以看出过滤且清除了script、href、onclik等关键参数,遇到这种过滤了关键参数的情况可以采用嵌套的方法,即scrscriptipt、hrhrefef等这种方式,如果只过滤一次,那么剩下的就可以组合成合法的XSS语句了。
第八关
照例弹窗测试,观察网页源码发现又是.htmlspecialchars()函数,且这次使用单引号都不行,代表value后面跟的是双引号,于是这里就不能从之前学习的各种有用到引号、标签的地方入手。关键字也惨遭重组。大小写也被限制。

那么只能从.htmlspecialchars()函数入手了。因为html正好有应对这种情况的功能,字符被转换成实体,也能使用字符编号来组成字符。那么将xss语句构造成字符实体编号,于是成功了。

字符实体是用一个编号写入HTML代码中来代替一个字符,在使用浏览器访问网页时会将这个编号解析还原为字符以供阅读。
这一关折磨了我很久,因为以为是由于.htmlspecialchars()函数才能使用字符编码的,网上搜索资料云里雾里的,在第三关尝试了很久发现不是。这一关的关键是要理解DOM型XSS,所谓DOM型XSS简单来说就是不通过服务器就可以修改网页的代码,属于反射型XSS的一种。
emmm,好像之前都是这么搞的,啊这。虽然原理还是一头雾水,但是效果还是清晰的,就是本关输入字符编号就会给href赋值,赋值的只要是伪协议就可以过关。
虽然不懂为什么原本输入字符会被过滤,可能是value被过滤重组了,然后将值给href,所以href赋值的是被重组后的语句,但是又有个矛盾的地方就是DOM不是说不与后端交互,那么href应该接收不到后端赋予的值才对,那为什么还是重组呢,真是令人费解,难道这一关不是DOM型XSS?希望将来能够有人解答我的疑惑吧。
第九关
打开网页直接审查代码,刚做完第八关,趁热发现熟悉的href,也不用弹窗测试了,直接上javascript:alert(1)。发现提示链接不合法。啥意思?没懂,直接打开源文件。
发现一个strpos()函数,这个函数只要发现后面的字符串在前面的字符串中出现了,那么就会返回位置,所谓的位置就是一个大于0的数字。

if语句判断,当条件为否的时候执行else,所以就说明字符串需要包含有http://这个字符串。

剩下的就按照第八关的思路对xss语句编码,然后组合就行了。

第十关
没有输入框,只能从GET入手,打开源码发现没有keyword的注入点,那么只能从下面几个隐藏的变量入手。尝试了一下,发现前面两个都不能使用,就第三个 t_sort 会对赋值产生反应,且过滤了<>,说明标签不能用。那么尝试事件。

事件没啥问题,双引号没有过滤,但是无法进行点击触发,这时又要用到一个新知识
accesskey属性

成功组合,不同浏览器触发的快捷方式也不同,我是火狐浏览器,使用ALT+SHIFT+x(自定义)快捷方式触发成功过关。

如果这种方法不成功的话网上还有一种方法可以将原本的hidden类型隐藏,然后设置成text类型,这样就会出现一个可输入的文本框了。

这篇博客详细记录了一位安全研究员在解决一系列XSS关卡时的思考过程和解决方案,涉及到关键字过滤、大小写敏感性、字符实体编码以及DOM型XSS的理解和应用。在面对不同的过滤机制时,通过嵌套、字符编码等技巧成功绕过防护,展现了XSS攻击与防御的博弈。同时,文中提到了accesskey属性在触发XSS中的作用,以及对于不同浏览器的兼容性考虑。

被折叠的 条评论
为什么被折叠?



