session劫持技术

目录：

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应用程序设计者要考虑的难题。