一种真正意义上的Session劫持
Author: jianxin [80sec]
EMail: jianxin#80sec.com
Site: [url]http://www.80sec.com[/url]
Date: 2008-12-24
From: [url]http://www.80sec.com/release/session-hijacking.txt[/url]
[ 目录 ]
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邮箱，譬如baidu的认证机制。我们可以经常遇到这样的情况，我在一个浏览器里开了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劫持 : [url]http://www.80sec.com/session-hijackin.html[/url]