OWASP-TOP-10漏洞之XSS
2023-3-18 20:45:32 Author: 渗透安全团队(查看原文) 阅读量:17 收藏

现在只对常读和星标的公众号才展示大图推送,建议大家能把渗透安全团队设为星标”,否则可能就看不到了啦

概念:

XSS攻击通常指的是通过利用网页开发时留下的漏洞,通过巧妙的方法注入恶意指令代码到网页,使用户加载并执行攻击者恶意制造的网页程序。这些恶意网页程序通常是JavaScript,但实际上也可以包括Java、 VBScript、ActiveX、 Flash 或者甚至是普通的HTML。攻击成功后,攻击者可能得到包括但不限于更高的权限(如执行一些操作)、私密网页内容、会话和cookie等各种内容。

原理:

HTML是一种超文本标记语言,通过将一些字符特殊地对待来区别文本和标记,例如,小于符号(<)被看作是HTML标签的开始,<title>与</title>之间的字符是页面的标题等等。当动态页面中插入的内容含有这些特殊字符(如<)时,用户浏览器会将其误认为是插入了HTML标签,当这些HTML标签引入了一段JavaScript脚本时,这些脚本程序就将会在用户浏览器中执行。所以,当这些特殊字符不能被动态页面检查或检查出现失误时,就将会产生XSS漏洞。

反射型(非持久型):

最直接的危害类型,跨站代码存储在服务器(数据库)。

存储型(持久型):

反射型跨站脚本漏洞,最普遍的类型。用户访问服务器-跨站链接-返回跨站代码。

DOM型:

DOM(document object model文档对象模型),客户端脚本处理逻辑导致的安全问题。

基于DOM的XSS漏洞是指受害者端的网页脚本在修改本地页面DOM环境时未进行合理的处置,而使得攻击脚本被执行。在整个攻击过程中,服务器响应的页面并没有发生变化,引起客户端脚本执行结果差异的原因是对本地DOM的恶意篡改利用。

常用的XSS攻击手段和目的有:

1、盗用cookie,获取敏感信息。

2、利用植入Flash,通过crossdomain权限设置进一步获取更高权限;或者利用Java等得到类似的操作。

3、利用iframe、frame、XMLHttpRequest或上述Flash等方式,以(被攻击)用户的身份执行一些管理动作,或执行一些一般的如发微博、加好友、发私信等操作。

4、利用可被攻击的域受到其他域信任的特点,以受信任来源的身份请求一些平时不允许的操作,如进行不当的投票活动。

5、在访问量极大的一些页面上的XSS可以攻击一些小型网站,实现DDoS攻击的效果。

反射型(非持久型):

复现条件:

环境:windows11+phpstudyV8+php5.4.45+Apache

程序框架:禅知CMS v5.6

特点:反射型xss,三次urldecode

payload构造思路:

构造payload的时候,先在漏洞处构造最终想要执行的目标代码,而后确定如何通过get传参,使得参数值传递到漏洞处,能完整还原为目标代码。借助工具,明确了通过get方式传递的参数值,到达漏洞处所经历的处理流程,从而勾画出完整流程图。

该图直观地反映了payload或 poc代码(即 "><script>alert(1);</script><" )以参数值的形式经过的多次解码操作,因此在执行面向XSS的代码审计时,随手勾画参数处理流程图,能够方便清晰直观的辅助完成安全审计工作。

payload流程图:

复现漏洞:

首先我们把网站搭建好

然后我们开始构造payload链接

http://localhost/czcms/www/index.php/user-deny-%252522%25253E%25253Cscript%25253Ealert%2525281%252529%25253B%25253C%25252fscript%25253E%25253C%252522

代码被成功执行

我们来将payload解urldecode看看原型是什么

我这里解了三次url编码才将原型给解出来,也证明了我们的构造思路是没有问题的

回顾上面一系列的测试,我们对URL传参进行了三次编码:

1.URL进入服务器时自动进行一次默认解码

2.进入deny方法之前进行参数处理时,会通过mergeParams方法中的urldecode函数进行第二次解码

3.在创建连接操作helper::createLink()中,通过parse_str()函数进行第三次编码

存储型(持久型):

复现条件:

环境:windows11+phpstudyV8+php5.4.45+apache

程序框架:骑士cms V3.4.0

特点:存储型xss,过滤绕过

payload构造思路:

通过分析程序代码探查可控参数经过哪些变换最终导致漏洞发生的过程,以流程图的形式记录下来,最后采用自下而上的的逆推方式构建payload,流程图如下,在最末端构建payload为href="javascript:alert(document.cookie)",需要使用<img src="闭合payload所在位置前后的标识符",并且按照参数在流程图自下而上,路径上可能经历的解码和转换操作进行编码,从而触发和测试存储型xss漏洞

payload流程图:

复现漏洞:

首先我们搭建好靶场环境

然后我们注册一个企业用户并且登录账号

我们找到公司信息,然后先把基本信息填好,不然是进不到上传营业执照的地方的

然后我们来到上传营业执照的地方

我们在上传的时候就按照他给的格式上传即可

然后我们将他的图片地址复制出来,一会我们要用到

http://localhost/74cms/data/certificate/2021/12/27/1640606362579.jpg

我们开始构造payload链接

http://localhost/74cms"><?a class="admin_&#102;rameset" href=ja&#118;asc&#114;ipt;ale&#114t(document.cookie)?><img src=74cms/data/certificate/2021/12/27/1640606362579.jpg><?/a?><?b a="

光这样写好了payload还是不够的,我们要对他在进行一次编码,编码后的内容如下

http%3A%2F%2Flocalhost%2F74cms%22%3E%3C%3Fa%20class%3D%22admin_%26%23102%3Brameset%22%20href%3Dja%26%23118%3Basc%26%23114%3Bipt%3Bale%26%23114t(document.cookie)%3F%3E%3Cimg%20src%3D74cms%2Fdata%2Fcertificate%2F2021%2F12%2F27%2F1640606362579.jpg%3E%3C%3F%2Fa%3F%3E%3C%3Fb%20a%3D%22

然后我们找到系统首页下方的申请友链

这里的随便填写就好,但是一定易于辨认

然后我们在填写好之后提交的同时抓取他的数据包

将抓包的link_url参数值替换为之前编码过的payload

然后发送到重放攻击模块中发送数据包查看结果

好的,我们添加成功,然后我们登录后台,选择广告,点击友情链接进行查看,我们点击破损的图片

点击后就会弹出我们的cookie了

弹出了cookie就说明此漏洞存在,并且我们成功利用此漏洞拿到了cookie信息

DOM型:

复现条件:

环境:windows11+phpstudyV8+php5.4.45+apache

程序框架:discuzV5.4

特点:存储型DOMxss,bbcode ,实体编码绕过

payload构造思路:

通过分析得知,dz论坛是可以允许用户在发帖的时候将邮箱格式的内容自动转换为超链接的形式,由此可知我们包含在帖子里的payload代码未被过滤掉(过滤不严谨),导致只通过bbcode2html方法将bbcode形式的字符串内容转换为html语法内容,使payload或poc成功嵌入前端显示对象中。当鼠标移动到该对象时,触发执行我们的payload或者poc代码。跟踪post参数传递和处理过程,分析bbcode2html方法转换机制,是构造payload或poc的关键。

复现漏洞:

我们先把dz论坛搭建好

然后我们去注册一个账号

接下来我们去发一篇帖子

emmm,那就等两分钟吧

我们在发帖子的时候把我们的payload代码放进去,如下图所示

写好以后我们提交帖子

然后我们使用有修改权限的账号对这个帖子进行编辑

我们在保存新的帖子页面的时候将鼠标移动过这篇帖子,我们的xss代码将会被触发

经过测试只能是数字才可以,其他的都不行,数字与特殊符号组合使用直接过滤掉特殊符号,数字与字母组合,直接不触发xss代码

我们可以看到xss代码已经被嵌入HTML的DOM模型中了,并且有实际效果,漏洞复现成功

(1)基于特征的防御。

XSS漏洞和著名的SQL注入漏洞一样,都是利用了Web页面的编写不完善,所以每一个漏洞所利用和针对的弱点都不尽相同。这就给XSS漏洞防御带来了困难,不可能以单一特征来概括所有XSS攻击。

传统的XSS防御在进行攻击鉴别时多采用特征匹配方式,主要是针对“javascript”这个关键字进行检索,但是这种鉴别不够灵活,凡是提交的信息中各有“javascript”时,就被硬性的被判定为XSS攻击。

(2)基于代码修改的防御。

Web页面开发者在编写程序时往往会出现一些失误和漏洞,XSS攻击正是利用了失误和漏洞,因此一种比较理想的方法就是通过优化Web应用开发来减少漏洞,避免被攻击:

1)用户向服务器上提交的信息要对URL和附带的的HTTP头、POST数据等进行查询,对不是规定格式、长度的内容进行过滤。

2)实现Session标记(session tokens)、CAPTCHA系统或者HTTP引用头检查,以防功能被第三方网站所执行。

3)确认接收的的内容被妥善的规范化,仅包含最小的、安全的Tag(没有javascript),去掉任何对远程内容的引用(尤其是样式表和javascript),使用HTTP only的cookie。

当然,如上操作将会降低Web业务系统的可用性,用户仅能输入少量的制定字符,人与系统间的交互被降到极致,仅适用于信息发布型站点。并且考虑到很少有Web编码人员受过正规的安全培训,很难做到完全避免页面中的XSS漏洞。

(3)客户端分层防御策略。

客户端跨站脚本攻击的分层防御策略是基于独立分配线程和分层防御策略的安全模型。它建立在客户端(浏览器),这是它与其他模型最大的区别,之所以客户端安全性如此重要,客户端在接受服务器信息,选择性的执行相关内容。这样就可以使防御XSS攻击变得容易,该模型主要由三大部分组成:

1)对每一个网页分配独立线程且分析资源消耗的“网页线程分析模块”;

2)包含分层防御策略四个规则的用户输入分析模块;

3)保存互联网上有关XSS恶意网站信息的XSS信息数据库。  

XSS攻击主要是由程序漏洞造成的,要完全防止XSS安全漏洞主要依靠程序员较高的编程能力和安全意识,当然安全的软件开发流程及其他一些编程安全原则也可以大大减少XSS安全漏洞的发生。这些防范XSS漏洞原则包括:

(1)不信任用户提交的任何内容,对所有用户提交内容进行可靠的输入验证,包括对URL、查询关键字、HTTP头、REFER、POST数据等,仅接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交,对其他的一律过滤。尽量采用POST而非GET提交表单;对“<”,“>”,“;”,“””等字符做过滤;任何内容输出到页面之前都必须加以en-code,避免不小心把htmltag显示出来。

(2)实现Session 标记(session tokens)、CAPTCHA(验证码)系统或者HTTP引用头检查,以防功能被第三方网站所执行,对于用户提交信息的中的img等link,检查是否有重定向回本站、不是真的图片等可疑操作。

(3)cookie 防盗。避免直接在cookie中泄露用户隐私,例如email、密码,等等;通过使cookie和系统IP绑定来降低cookie泄露后的危险。这样攻击者得到的cookie没有实际价值,很难拿来直接进行重放攻击。

(4)确认接收的内容被妥善地规范化,仅包含最小的、安全的Tag(没有JavaScript),去掉任何对远程内容的引用(尤其是样式表和JavaScript),使用HTTPonly的cookie。

翻到文章最底部点击“阅读原文”下载链接


付费圈子

欢 迎 加 入 星 球 !

代码审计+免杀+渗透学习资源+各种资料文档+各种工具+付费会员

进成员内部群

星球的最近主题和星球内部工具一些展示

关 注 有 礼

关注下方公众号回复“666”可以领取一套领取黑客成长秘籍

 还在等什么?赶紧点击下方名片关注学习吧!


群聊 | 技术交流群-群除我佬

干货|史上最全一句话木马

干货 | CS绕过vultr特征检测修改算法

实战 | 用中国人写的红队服务器搞一次内网穿透练习

实战 | 渗透某培训平台经历

实战 | 一次曲折的钓鱼溯源反制

免责声明
由于传播、利用本公众号渗透安全团队所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,公众号渗透安全团队及作者不为承担任何责任,一旦造成后果请自行承担!如有侵权烦请告知,我们会立即删除并致歉。谢谢!
好文分享收藏赞一下最美点在看哦

文章来源: http://mp.weixin.qq.com/s?__biz=MzkxNDAyNTY2NA==&mid=2247500928&idx=3&sn=fe21cd383799abc3a431a161e1139cf6&chksm=c176392ff601b03964a6612a498c28ea42f671b8157939ce478d01ea9326d4ad253ee856281d#rd
如有侵权请联系:admin#unsafe.sh