快捷导航

XSS浅谈-2

[复制链接]
uuu 发表于 2018-5-29 23:45 | 显示全部楼层 |阅读模式
查看: 2548  |  回复: 0

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
来看这份代码:

乍一看,哇!自带script标签。再一看,WTF!填入的内容被放在了变量里!
这个时候就要我们手动闭合掉两个双引号来实现攻击,别忘了,javascript是一个弱类型的编程语言,变量的类型往往并没有明确定义。
思路有了,接下来要做的就简单了,利用语句如下:
http://192.168.1.102/xss/example6.php?name=";alert("I am coming again~");"
效果如图。

回看以下注入完代码的网页代码,发现我们一直都在制造巧合。。
先是闭合引号,然后分号换行,加入代码,再闭合一个引号,搞定!
  • 组合各种方式

在实际运用中漏洞的利用可能不会这么直观,需要我们不断的尝试,甚至组合各种绕过方式来达到目的。
介绍完一些常用的绕过方式,再倒回来讲一下XSS分类,因为下面讲具体的应用时会用到。
XSS攻击大致上分为两类:
一类是反射型XSS,又称非持久型XSS,
一类是储存型XSS,也就是持久型XSS。
什么是反射型XSS
其实,我们上面讲XSS的利用手段时所举的例子都是非持久型XSS。
也就是攻击相对于访问者而言是一次性的,具体表现在我们把我们的恶意脚本通过url的方式传递给了服务器,而服务器则只是不加处理的把脚本“反射”回访问者的浏览器而使访问者的浏览器执行相应的脚本。
也就是说想要触发漏洞,需要访问特定的链接才能够实现。
什么是储存型XSS
它与反射型XSS最大的不同就是服务器再接收到我们的恶意脚本时会将其做一些处理。
例如储存到数据库中,然后当我们再次访问相同页面时,将恶意脚本从数据库中取出并返回给浏览器执行。这就意味着只要访问了这个页面的访客,都有可能会执行这段恶意脚本,因此储存型XSS的危害会更大。
还记得在文章开头提到的留言板的例子吗?那通常就是储存型XSS。当有人在留言内容中插入恶意脚本时,由于服务器要像每一个访客展示之前的留言内容,所以后面的访客自然会接收到之前留言中的恶意脚本而不幸躺枪。
这个过程一般而言只要用户访问这个界面就行了,不像反射型XSS,需要访问特定的URL。
实例应用
1、劫持访问
劫持访问就是在恶意脚本中插入诸如的代码,那么页面就会跳转到百度首页。
劫持访问在持久型和非持久型XSS中都比较常被利用。持久型XSS中劫持访问的危害不用说大家都清楚,但有人会问非持久型XSS中劫持访问有什么作用呢?
很简单,试想下像http://qq.comhttp://baidu.com这样的域名下出现非持久型XSS,那么在发送钓鱼链接时就可以通过http://qq.com等域名进行跳转,一般人一看到http://qq.com之类的域名警惕性会下降,也就更容易上当了。
2、盗用cookie实现无密码登录
具体原理上文已经提到,这里做一个具体演示。由于盗取的cookie需要传回给攻击者,因此往往需要一个服务器来接收盗取的cookie,这也就是xss平台的作用了。网上的xss平台很多,但动手搭建一个也不难,建议有条件的自己搭建。
首先登录平台后台获取到js脚本地址为http://127.0.0.1/XSS/template/default.js,所以我们需要做的是把这段代码植入指定页面。
(这里以DVWA渗透测试平台为例)

我们发现网页对于message长度有限制。审查元素看一下。
发现最大长度有限制,但这仅仅是前端的限制,直接双击修改成更大的数字即可。再次尝试,没问题,我们已经将脚本植入完毕。
然后就是坐等别的用户访问这个界面。
这时,另一个用户gordonb登录并访问了留言界面,那么他的cookie就会被窃取。我们可以从xss平台的后台获取到。
拿到cookie之后要登录他的帐号就好办了。
打开登录界面,调出火狐的firebug插件,调至cookie选项卡(注意,如果你的firebug插件没有cookie选项卡,请再安装firecookie插件即可看到)
然后依次点击cookies-create cookie,随后再弹出的界面中填入两个xss平台获取到的cookie,如图

这里注意要把我箭头所指的地方勾上,这是设置cookie有效期的地方,不然会在设置完下一秒cookie就失效。完成之后再次刷新页面,发现已经不是之前的登录界面了,而是登录后的界面。至此,一个从cookie窃取到利用的过程就已完成。

3、配合csrf攻击完成恶意请求
先简单解释以下csrf攻击。Csrf攻击就是在未经你许可的情况下用你的名义发送恶意请求(比如修改密码,银行转账等),下面演示一个用xss配合csrf修改用户密码的例子。
首先对修改用户密码的界面进行抓包。

发现没有对原密码进行校验。于是一股邪恶的力量油然而生:要是在xss的恶意脚本中自动提交get请求修改密码的话。。
说干就干,具体插入语句如下:
<script type="text/javascript" src="http://127.0.0.1/test/vulnerabilities/csrf/?password_new=123456&password_conf=123456&Change=Change#"></script>
有人会问,这不是引用脚本吗?其实不然,本质上这还是发起了一起get请求,因此可以直接使用。与上例一样,插入到message中,再坐等上钩。等下一个用户访问该界面时,密码就会被改为123456了。
我们再看下访问该页面时的抓包情况,发现每次访问该页面都发送了更改密码的请求

效果看数据库(密码md5加密)
访问了该页面的用户密码都被更改了。
防范手段
都说知己知彼方能百战不殆,知道了xss攻击的原理那么防御的方法也就显而易见了。
  • 首先是过滤。对诸如<script>、<img>、<a>等标签进行过滤。
  • 其次是编码。像一些常见的符号,如<>在输入的时候要对其进行转换编码,这样做浏览器是不会对该标签进行解释执行的,同时也不影响显示效果。
  • 最后是限制。通过以上的案例我们不难发现xss攻击要能达成往往需要较长的字符串,因此对于一些可以预期的输入可以通过限制长度强制截断来进行防御。
后话
安全攻防双方的博弈永远都不会停止,也正是这种博弈推进了信息安全的发展。究竟是道高一尺还是魔高一丈很难定论。其实安全问题归根结底还是一个信任的前提。什么输入值得信任?什么输入不值得信任需要特殊处理是安全人员常常要思考的一个问题。
(以上内容如有错误之处,敬请指正,谢谢!)

永远支持黑客共享吧!
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

本站内容均来自于互联网,仅供参考,请遵循当地相关法律法规。

快速回复 返回顶部 返回列表