日期：2009-05-24 17:24:00 来源：本站整理
一种真正意义上的Session劫持[网络技术]
本文“一种真正意义上的Session劫持[网络技术]”是由七道奇为您精心收集，来源于网络转载，文章版权归文章作者所有，本站不对其观点以及内容做任何评价，请读者自行判断，以下是其具体内容：
Author: jianxin [80sec]
EMail: jianxin#80sec.com
Site: http://www.80sec.com
Date: 2008-12-24
From: http://www.80sec.com/release/session-hijacking.txt
[ 目录 ]
0×00 利用程序认证计划后台
0×01 通例攻击思绪及缺陷
0×02 操纵利用程序计划缺陷举行Session劫持的攻击原理
0×03 Session劫持的大致思绪及意义
0×04 若何防备这种攻击
0×00 利用程序认证计划后台
一个利用程序在计划的历程中,为了实现对资源和恳求举行管理,用户信息认证是非常重要的一环.由于HTTP恳求的无衔接性,普通的利用程序都是通过Cookie大概Session来完成认证工作,通过将加密的用户认证信息存储到Cookie中,大概通过赋予客户端的一个Token,普通也就是所说的SessionId来在服务器端直接完成认证和获得用户的身份信息,不管哪一种方法,实际上在HTTP协议里都是通过Cookie来实现的,差别的是Cookie大概可以对比长期地存储在客户端上,而Session常常在会话完毕之后服务器监督会话不处于活动状况而予以销毁.
0×01 通例攻击思绪及缺陷
我们研究的web安全,常常很多时刻其实就是在攻击认证,包含非常风行的客户端攻击XSS,传统的办法是我们可以截取Cookie来假造成别人的身份来得到认证.各种利用程序为了实现自己独特的功效利用,在认证机制计划的时刻并不一致,比方有的完好将认证信息（用户密码信息）加密存储到客户端里,只要用户密码信息不改正,便可以一向操纵这个认证信息来登录利用程序.也有的是将认证通过后利用程序赋予客户端一个Token,这个Token存储在Cookie里,这样当客户端登录的时刻便可以通过这个Token得到对应的身份,这样只要这个Cookie不被删除,便可以永久的处于登录状况.而别的的一些利用程序将Token安排到Session里,当客户端退出利用程序之后大概客户端在一段时间无呼应之后,服务器就销毁这个Session,并且因为是Session里,所以客户端浏览器关闭之后,这个Session也从浏览器内存里销毁了.
我们常用的跨站脚本攻击非常常用的一个攻击伎俩就是去攻击利用程序的认证,而由于服务器实现认证的时刻存在的一些漏洞和机制的一些辨别,攻击成果也常常显得差别.关于利用程序来说,为了保证绝对的安全,服务器应当将Cookie和客户端绑定,比方将客户端的加密IP也存储到Cookie里,假如发现Ip发生改变便可以认为是Cookie发生了泄露,应当撤消这个Cookie,但是这样一来,用户体验就非常不好,所以普通的利用程序都没有对Cookie做太多的战略,这就为我们的客户端身份盗取供应了可乘之机.所以问题就集合到认证机制的处理上,关于第一种情形,大大都的中小型利用程序的前台都是利用的这种认证方法,只要得到了Cookie便可以永久得到别人的身份.而第二种情形也对比常见,比方Google就是利用的这种机制,只要盗取了Cookie,别人只关闭利用程序也不退出利用程序的时刻便可以得到别人的身份（之前别人退出都可以得到别人的身份,后来他们做了改良）.剩下对比麻烦的就是第三种情形最令人头疼,因为是Session认证,所以别人退出大概关闭浏览器而与服务器的沟通完毕之后,Session在一按时间内也被销毁.但是我们发现一些程序在计划的时刻存在问题,大概招致我们操纵Session的机制在服务器上永久的产生一个后门（在某些计划不严的程序里,大概改正密码也不能消撤除这种后门）,我这里把它称为一种真正意义上的Session劫持.
0×02 操纵利用程序计划缺陷举行Session劫持的攻击原理
普通的Session劫持都是得到身份之后盼望对方不要点击退出,并且假如在这段时间里没有及时操纵Session,Session也会因为自己的机制而举行自我销毁,这样获得到的Session就失去了效果,这里对比典型的利用有很多,比方163邮箱,比方百度的认证机制.我们可以常常碰到这样的情形,我在一个浏览器里开了webmail然后新翻开一个浏览器开了webmail,然后我第一个浏览器退出了并不影响第二个的账户,二者互不影响,其实是因为他们获得到了两个SessionId,这在利用程序里大概是作为用户体验考虑的,但是恰是这种机制存在宏大的安全漏洞.
Session信息是以一个SessionId大概表现为暂时Cookie的Token的情势发送的,而我们在实现了XSS的时刻其实是可以操作Cookie的了,可以想象,假如我们赋给浏览器一个和Session Cookie名字相同而值差别的Cookie会怎么样?通过我们的测试发现,实际上两个Cookie都是被发送出去的,在HTTP头里表现为呈现两个一样的COOKIE,那么服务器会挑选哪个Cookie作为实际获得的COOKIE变量呢?我们测试的时刻发现实际上是以第一个呈现的COOKIE为准的,而不管发送过来的是Session Cookie还是Store Cookie,所以我们便可以操纵Javascript改变客户端的Session Token了.
0×03 Session劫持的大致思绪及意义
这样我们的思绪就很清楚,我们要实现的是Session劫持,而不是传统的Session盗取,我们通过覆盖这个Session Token为一个无效值,服务器会认为用户身份为未登录,然后会要求用户再次登陆,在这个时刻我们可以盗取到有效的Session Token值.用户再次登陆之后,他得到新的Session Token,而由于利用程序的机制,之前的Session Token并没有失效,这样服务器上就存在两个有效的Session Token了.我们通过研究利用程序的Session超机会制和心跳包机制,便可以长期地使这个Session有效.而接下来假定用户很注意安全,他有退出利用程序的利用习惯,他销毁了他的Session Token,但是仍旧有一个Session Token被我们掌握.这种办法的毒辣在于,即便用户意识到Session Token被盗取,假如某些利用程序的计划有问题,即便用户改正密码,他也不能掌握服务器注销掉被我们掌握的会话,他的Session永久被我们掌握了,他也永久不知道这个Session Token是多少.
0×04 若何防备这种攻击
我们可以看到,这种攻击是由于利用程序在计划的时刻考虑不周造成的,我们可以在计划认证的时刻就强行要求客户端必须唯一,并且认证信息在多少天之后就过期的机制,但是很明显这样会和将COOKIE和ip绑定一样,大概带来不好的用户体验,如安在计划的时刻意识到这个问题并且衡量利用和安全的均衡点才是web利用程序计划者要考虑的难题.
本站内容均为原创,转载请务必保存签名与链接!
一种真正意义上的Session劫持:http://www.80sec.com/session-hijackin.html
以上是“一种真正意义上的Session劫持[网络技术]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：
| 本文地址： | 与您的QQ/BBS好友分享! |
- 好的评价 如果您觉得此文章好，就请您
0%(0) 
- 差的评价 如果您觉得此文章差，就请您
0%(0) 
中查找“一种真正意义上的Session劫持”更多相关内容
中查找“一种真正意义上的Session劫持”更多相关内容评论内容只代表网友观点，与本站立场无关！
评论摘要(共 0 条，得分 0 分，平均 0 分)
查看完整评论