Pikachu靶场通关记录：反射型XSS(GET)学习与踩坑

最近在巩固Web安全的基础漏洞想着拿经典的Pikachu靶场练练手。今天正好刷到了跨站脚本攻击里的“反射型XSS(GET)”这一关顺手记录一下整个测试过程和踩坑经历顺便结合我的专业方向从安全运维的角度总结一下怎么防御。声明一下本文所有的测试都是在本地搭建的虚拟机环境里进行的大家练习技术一定要遵守网络安全法哦。第一步观察正常业务逻辑打开靶场这一关的页面界面挺简单的提示“你喜欢哪位NBA球员”。我随手输入了一个 Kobe点击提交测试一下。观察一下页面下面回显了“kobe的扣篮图片”。这时候留意一下浏览器上方的地址栏很明显这是一个GET请求我们输入的Kobe被当做message参数直接拼接到URL里面了。这说明页面有把用户输入原样输出的动作很可能存在XSS。第二步构造弹窗代码与前端踩坑既然输入什么就显示什么那我就直接上最经典的弹窗测试代码scriptalert(XSS)/script结果有趣的事情发生了这就遇到了新手经常会碰到的一个小坑当我在输入框里敲到 scriptalert(XSS) 的时候键盘就敲不进去了。很明显这摆明了是前端对输入框的长度做了限制。第三步绕过前端限制大家都知道在安全测试里面纯前端的限制基本等于没有就是个纸老虎。这里记录两种简单的绕过方式第一种办法是审查元素修改页面。直接按F12打开浏览器的开发者工具用那个小箭头选中网页上的输入框。在看下方源码的时候能清楚地看到有个 maxlength20 的属性限制了长度。我直接双击它把20改成了200这下就能把整段代码完整输进去了。然后我们输入测试代码scriptalert(XSS)/script可以看到是成功了的。第二种办法更粗暴因为它是GET请求其实我们完全可以无视那个输入框直接去浏览器最上面的地址栏里把 message 后面的内容替换成我们的测试代码按回车是一样的效果。把完整代码提交后页面立马弹出了 XSS 的警告框。这说明这个接口确实存在明显的反射型XSS漏洞。作为想往安全运维方向发展的人不能光会弹出个框还得知道为什么会这样。我去翻了一下靶场的PHP后端源码发现它是直接通过 $_GET 获取 message 的值。拿到值以后连个基础的过滤和转义都没做直接用字符串拼接的方式塞到了HTML代码里发回给前端。浏览器引擎在渲染的时候遇到 script 标签就老老实实当成JS代码给执行了。