先看Pikachu对于XSS的解释
XSS(跨站脚本攻击)概述
Cross-Site Scripting 简称为“CSS”,为避免与前端层叠样式表的缩写”CSS”冲突,故又称XSS。一般XSS可以分为如下几种常见类型:
1.反射性XSS;
2.存储型XSS;
3.DOM型XSS;
XSS漏洞一直被评估为web漏洞中危害较大的漏洞,在OWASP TOP10的排名中一直属于前三的江湖地位。
XSS是一种发生在前端浏览器端的漏洞,所以其危害的对象也是前端用户。
形成XSS漏洞的主要原因是程序对输入和输出没有做合适的处理,导致“精心构造”的字符输出在前端时被浏览器当作有效代码解析执行从而产生危害。
因此在XSS漏洞的防范上,一般会采用“对输入进行过滤”和“输出进行转义”的方式进行处理:
输入过滤:对输入进行过滤,不允许可能导致XSS攻击的字符输入;
输出转义:根据输出点的位置对输出到前端的内容进行适当转义;
下面是我的理解:
所谓XSS漏洞,就是开发人员对用户输入没有进行过滤或过滤不严谨导致用户可以插入恶意JavaScript代码并执行恶意操作而已,常用来盗取Cookie和与CSRF打组合拳,当然也可以拿来搞恶作剧,危害程度取决于攻击者脑洞大小。
实现前提:对用户输入过滤不当,对内容输出转义不当
- 反射性xss(get):
来个经典的,看看会怎么样。
盲猜前端input属性有maxlength标签限制输入字符长度,改大或删掉就行
果然如此,改大一点,然后再试试
成功弹出,再看看前端源码的变化
发现把我们的输入当成了代码在执行,至此第一关结束,总结一下就是,这一关要注意会不会对我们的输入进行过滤之类的,如果过滤了,该怎么去闭合或者绕过,然后成功弹窗。
- 反射性xss(post):
看到post就知道,肯定有表单提交之内的
果然如此,那就先登录,根据右上角提示,用户名密码是admin/123456
登录之后,有个文本框和提交,老样子,输入经典的,观察结果
直接成功,无过滤等限制,这关目的锻炼登陆后盗取cookie,所以我们再输入看看如何
成功弹出了我们登录之后的cookie,此关结束,下一关
- 存储型xss:
顾名思义,会把我们的输入放到数据库永久存储,每次打开页面都会触发,在实际生活中,对应到用户在留言板插入盗取cookie的xss,然后管理员登录后台不小心中招泄露cookie。
老样子,输入经典的
然后就存起来了,所有人访问这个页面都会看到,正常利用应该是拿来盗取cookie,并发送邮件到xss平台。
- DOM型xss:
老样子,经典插入
观察结果
跑到a标签的href属性里面去了,给它闭合掉试试
没用,既然如此,那就好好看看JavaScript代码吧,先照着提示做,’>
鼠标经过,成功弹出,再试试第二个:’ onclick=”alert(‘xss’)”>
鼠标点击,成功弹出,分析一下原理
JavaScript代码说,会把你的输入内容和 what do you see?来进行拼接,因此只需要闭合一下前面的href=’即可,所以提示说:’>和’onclick=”alert(‘xss’)”>,前者是闭合a标签,然后增加一个图片标签来制作xss,后者是闭合href属性,然后添加一个点击事件属性来制作xss。
但是我输入:’><’是没效果的
目前不知道为什么,估计是这种把用户输入的内容放进某个标签内部的做法,只能通过闭合加标签或加属性来触发xss吧,不能再靠闭合直接输入来触发xss了,没用
思考了一下,DOM型xss,由于是JavaScript前端操作你的输入内容和显示,所以说就不能通过来弹窗了,应该只能通过闭合标签加标签加事件来弹窗,或者闭合属性加属性来弹窗。正因为是前端操作用户输入的内容,所以DOM型xss,也是特殊的反射性。
- DOM型xss-x:、
既然还是DOM型,那么照第4关所言,就依然是闭合标签加标签事件或者闭合属性加属性两种做法。
一样的道理:’>和 ‘ onclick=”alert(‘xss’)”>
搞不明白,既然几乎没区别,为什么单独开一个关卡呢,还叫DOM型xss-x,什么意思,还有右上角提示说dom型XSS是鸡肋吗? 又是什么意思?
通过去搜了一下,发现说这一关的url里有我们输入的payload
果然如此,想必与DOM型xss的区别是,这一关可以通过构造url就可以实现DOM型xss攻击。
参考文章:传送阵
xss之盲打:
所谓盲打就是插入的内容,不会在前端显示,所以我们不能在前端看到相应的反馈,而是将payload插入到后台,如果后台没有对xss进行过滤,那么后台就会被插入,可以获得管理员的cookie等。
登陆后台:登录地址admin_login.php 用户密码 admin/123456
既然如此,这关想表达的就是,这次的xss仅只针对登陆后的管理员可见,那我们输入,然后去后台看看
成功弹出管理员的cookie,在现实世界中,正常情况是,有一个留言板,然后用户输入后看不见输入内容,只有管理员登陆后台才可见,这种时候就可以去xss平台生成xss代码,插入到插入点,然后坐等盗取到管理员cookie,这就是xss盲打的含义。下一关xss之过滤:
一看到这种就先经典插入再说。
没有弹窗,看前端源码,看看是怎么处理输入内容的,找了一遍,发现没有,只能自己乱试了。
发现输入
奈斯,成功了,输入tmac有个小彩蛋。至此,XSS关卡全部结束。
小小总结一下:pikachu当中的XSS,主要是让你认识类型和绕过过滤而已,并没有锻炼你使用XSS拿到有危害的东西,看样子只能去其他地方实战了,这里给个XSS的修复建议吧。
XSS成功的前提是两个,一是对用户输入过滤不严谨,二是对用户内容输出未处理。
- 对于用户输入,进行正则表达式查找替换,不区分大小写
- 对用户输入内容进行输出时,进行html实体转换。
- 对输入输出内容里面的什么” ‘ < > script javascript统统处理掉
- 终极办法:找个牛逼的waf,什么都解决了。
pikachu入个门还不错,但是深入靠不住,以后不管是xss还是sql都得自己去深入,下一关,CSRF。