会话劫持工具

『壹』 常见WEB攻击之Session攻击(会话劫持)

Session对于Web应用无疑是最重要的，也是最复杂的。对于web应用程序来说，加强安全性的第一条原则就是 – 不要信任来自客户端的数据，一定要进行数据验证以及过滤，才能在程序中使用，进而保存到数据层。 然而，为了维持来自同一个用户的不同请求之间的状态， 客户端必须要给服务器端发送一个唯一的身份标识符(Session ID)。 很显然，这和前面提到的安全原则是矛盾的，但是没有办法，http协议是无状态的，为了维持状态，我们别无选择。 可以看出，web应用程序中最脆弱的环节就是session，因为服务器端是通过来自客户端的一个身份标识来认证用户的， 所以session是web应用程序中最需要加强安全性的环节。

基于session的攻击有很多种方式。大部分的手段都是首先通过捕获合法用户的session, 然后冒充该用户来访问系统。也就是说，攻击者至少必须要获取到一个有效的session标识符，用于接下来的身份验证。

在Session攻击中又分为会话劫持和会话固定两种，篇幅原因下面简单介绍会话劫持攻击的攻击方式和防御措施

会话劫持（Session hijacking），这是一种通过获取用户Session ID后，使用该Session ID登录目标账号的攻击方法，此时攻击者实际上是使用了目标账户的有效Session。会话劫持的第一步是取得一个合法的会话标识来伪装成合法用户，因此需要保证会话标识不被泄漏。

1、 目标用户需要先登录站点；

2、 登录成功后，该用户会得到站点提供的一个会话标识SessionID；

3、 攻击者通过某种攻击手段捕获Session ID；

4、 攻击者通过捕获到的Session ID访问站点即可获得目标用户合法会话。

1、 暴力破解：尝试各种Session ID，直到破解为止；

2、 预测：如果Session ID使用非随机的方式产生，那么就有可能计算出来；

3、 窃取：使用网络嗅探，XSS攻击等方法获得。

确保User-Agent头部信息一致的确是有效的，如果会话标识通过cookie传递，攻击者能取得会话标识，他同时也能取得其它HTTP头部。由于cookie暴露与浏览器漏洞或跨站脚本漏洞相关，受害者需要访问攻击者的网站并暴露所有头部信息。则攻击者只需重建头部即可进行攻击了。

因此前提需要做好XSS防御

对于常用框架来说，其内部Session的实现机制虽然不是很安全，但是关于生成Session ID的环节还是比较安全的，这个随机的Session ID往往是极其复杂的并且难于被预测出来，所以，对于第一、第二种攻击方式基本上是不太可能成功的。

对于第三种方式大多使用网络数据通讯层进行攻击获取，可以使用SSL进行防御。

在应用层上也可以做出相应的防御措施：

目前有三种广泛使用的在Web环境中维护会话（传递Session ID）的方法：URL参数，隐藏域和Cookie。其中每一种都各有利弊，Cookie已经被证明是三种方法中最方便最安全的。从安全的观点，如果不是全部也是绝大多数针对基于Cookie的会话管理机制的攻击对于URL或是隐藏域机制同样适用，但是反过来却不一定，这就让Cookie成为从安全考虑的最佳选择。

1、 更改Session名称。PHP中Session的默认名称是PHPSESSID，此变量会保存在Cookie中，如果攻击者不分析站点，就不能猜到Session名称，阻挡部分攻击。

2、 关闭透明化Session ID。透明化Session ID指当浏览器中的Http请求没有使用Cookie来存放Session ID时，Session ID则使用URL来传递。

3、 设置HttpOnly。通过设置Cookie的HttpOnly为true，可以防止客户端脚本访问这个Cookie，从而有效的防止XSS攻击。

4、 关闭所有phpinfo类mp request信息的页面。

5、验证HTTP头部信息

在http访问头文件：[Accept-Charset、Accept-Encoding、Accept-Language、User-Agent]，浏览器一般发出的头部不会改使用User-Agent检测请求的一致性。

『贰』 怎样应对会话劫持：以Firesheep为例

黑客用这个工具就可以访问用户访问流行网站时所使用的账户，如大名鼎鼎的Facebook账户等。其实，该工具就是利用了一个业内人士都熟知的一个漏洞：会话支持。因为到目前为止，还没有完全解决这个漏洞。 WEB认证基础知识 1、用户访问需要认证的网站。 2、用户提供一个用户名和口令进行验证。 3、网站验证用户口令，如果通过，则准许用户登录进入，并将一个cookie提供给用户的浏览器。此cookie用于唯一的标识会话。 4、用户继续访问网站。在用户请求一个新网页时，浏览器都会发送cookie和用户请求，提醒Web服务器：该请求是前面的认证连接的一部分。 在多数情况下，Web开发人员和网站管理员都会使用HTTPS加密来保护这个过程的第二步，他们都知道如果其它人员能够访问其他用户的用户名和口令，就可以轻易地获得访问权。在许多情况下，他们会转而使用一个不加密的HTTP连接，以便于实现Web通信的其余部分，其中也包括cookie的交换。 会话劫持攻击和Firesheep 下面谈谈会话劫持攻击。如果窃听者成功地截获了发生在第四步的任何通信，他就可以轻易地访问cookie。一旦知道了cookie的内容，窃听者就可以伪造一个HTTP请求，使用cookie访问用户的账户。 防御Firesheep等会话劫持攻击 防御Firesheep及其它会话劫持攻击的最佳防线在于WEB开发人员和WEB服务器的管理人员。如果你开发的WEB应用程序依赖于cookie来实现会话管理，就要确保以一种安全方式来管理会话。下面介绍几个方法： 1、仅通过SSL来发送cookie。如果你要求浏览器在传输之前加密cookie，在传输中就不易遭受攻击。 2、要限制能够利用cookie的应用程序。你还应当设置cookie，要尽可能地限制其使用。至少，要将cookie设置为仅对可信域中的系统可用。理想情况下，还应仅允许可信域中的特定服务器访问这些cookie，还有设置路径(path)选项，仅准许特定的应用程序可以访问cookie。 3、限制cookies仅能使用HTTPS。你还可以使用httponly标记，要求浏览器仅能通过HTTP/HTTPS直接将cookie提交给服务器。这会防止攻击者通过JavaScript攻击访问cookie。 如果你是一位终端用户，你可能无法控制cookies的配置方法，但你可选择下面的一些措施： 1、限制不提供HTTPS连接的网站的使用。 2、通过VPN建立连接。如果你在一个有风险的地方上网，并且担心窃听者会执行会话劫持攻击，可以试着连接到工作场所的VPN(虚拟私有网络)，并使用此连接来加密你的网络通信。 结束语Firesheep所代表的绝不仅仅是一种软件威胁。它以一种WEB应用程序执行会话管理的方式突显了一种底层漏洞。虽然有一些临时的解决方案可以帮助企业限制这种工具所造成的短期损害，但WEB应用程序社团应当紧密协作，并开发可以解决会话劫持攻击的长期解决方案。否则，在下一个黑客工具出现之后，我们依旧容易遭受攻击。

『叁』 中间人攻击的会话劫持

会话劫持”（SessionHijack）是一种结合了嗅探以及欺骗技术在内的攻击手段。广义上说，会话劫持就是在一次正常的通信过程中，攻击者作为第三方参与到其中，或者是在数据里加入其他信息，甚至将双方的通信模式暗中改变，即从直接联系变成有攻击者参与的联系。简单地说，就是攻击者把自己插入到受害者和目标机器之间，并设法让受害者和目标机器之间的数据通道变为受害者和目标机器之间存在一个看起来像“中转站”的代理机器（攻击者的机器）的数据通道，从而干涉两台机器之间的数据传输，例如监听敏感数据、替换数据等。由于攻击者已经介入其中，他能轻易知道双方传输的数据内容，还能根据自己的意愿去左右它。这个“中转站”可以是逻辑上的，也可以是物理上的，关键在于它能否获取到通信双方的数据。
典型的会话劫持是利用TCP/IP的工作原理来设计攻击的。在谈TCP/IP会话劫持前先解释一下TCP/IP用于确认数据传输的判断机制。许多人一定都有过这样的疑问：TCP/IP是使用点对点（PointtoPoint）连接进行数据传输的，但是它是如何知道上一条数据和下一条数据存在的联系的呢。如果发送数据后不慎掉线，恰好另一个人接着IP地址连接到了Internet，那他会不会收到服务器返回数据。其实只要看过TCP/IP协议的书籍就会明白，TCP协议采用了两种条件来确认每条已经建立连接的TCP通道，第一个是基础连接确认，即TCP连接中的四大必备条件：源IP、源TCP端口、目标IP、目标TCP端口；第二个条件是“序号标识”（Sequencenumbers，SEQ），它们是成对出现的，分为“Sequence”（SEQ，序号字段）和“AcknowledgementSequence”（ACKSEQ，确认序号字段），TCP每次建立一个连接时，会给双方指定这样一条规则：序号字段指出了本报文中传送的数据在发送主机所要传送的整个数据流中的顺序号，而确认序号字段指出了发送本报文的主机希望接收的对方主机中下一个八位组的顺序号。（这里可能比较难理解，可以举个不专业的例子解释：流水线上的工人被规定好了每人负责安装8个不同的零件，则每次传输到他们手上的都应该是只留下给他们安装的8个零件位置，这就是序号字段；而下一个工人则被规定在前一个工人的基础上安装另一个部分的8个零件，这就是确认序号字段，如果这个工人发现传到自己手上的产品多了或少了零件，则说明前一个工人出错，这个产品就被从流水线提取出来返工，这就是TCP对序号的严密审查和丢弃制度）。TCP如此谨慎，就是为了避免出现前面提到的假设，虽然这种假设发生的几率很小（需要满足TCP的基础连接确认条件），但是它总有机会发生的。然而不幸的是，这对序号是可以预测的，因为TCP必须遵从以下守则：一台主机即将发出的报文中的SEQ值应等于它所刚收到的报文中的ACKSEQ值，而它所要发送报文中的ACKSEQ值应为它所收到报文中的SEQ值加上该报文中所发送的TCP数据的长度，即两者存在“本次发送的SEQ=上次收到的ACKSEQ；本次发送的ACKSEQ=上次收到的SEQ+本次发送的TCP数据长度”的联系。知道这个规律后，攻击者就不难发起“中间人攻击”了，他只需要设法监听到受害者TCP连接中的第一个条件（源IP、源TCP端口、目标IP、目标TCP端口），就可以得知其中一台主机对将要收到的下一个TCP报文段中SEQ和ACKSEQ值的要求，这样攻击者就能在原来的合法主机收到另一台合法主机发送的TCP报文前根据所截获的信息向该主机发出一个符合条件二（序号标识）的TCP报文，如果该主机先收到攻击报文，就会受到欺骗而把合法的TCP会话建立在攻击主机与被攻击主机之间，而且攻击报文会让被攻击主机对下一次要收到的TCP报文中的确认序号值的要求发生变化，最终使另一台合法的主机向被攻击主机发出的报文被拒绝，这种模式被称为“主动劫持”。换句话说，就是其中一方合法主机被攻击者掠夺了连接的权限，而攻击者却成为了合法的连接方之一。这种会话劫持让攻击者避开了被攻击主机对访问者的身份验证和安全认证，从而使攻击者直接进入对被攻击主机的的访问状态，因而危害严重。例如，你刚向某站点发送完账户密码，就被攻击者抢先冒充你的TCP连接上了，那你的损失可就难预料了。不过，会话劫持对网络环境的一点要求可以让大家松口气，它必须在使用MAC寻址的网络环境中才能发挥作用，必要时还要配合ARP协议欺骗，能同时满足这两个条件的只有局域网。而广域网不是靠MAC地址来查找计算机的，因此攻击者很难从现有的广域网结构里插入到某两台计算机之间。