6.3 处理会话令牌过程中的漏洞

应用程序以不安全的方式处理令牌表现在许多方面，致使令牌易于遭受攻击。例如，如果以某种方式将令牌透露给攻击者，那么即使攻击者无法预测令牌，也仍然能够劫持用户的会话。

6.3.1 日志记录导致的令牌泄露

许多应用程序为管理员和其他支持人员提供监控和控制应用程序运行时状态（包括用户会话）的功能。例如，帮助用户解决疑难的服务台工作人员可能会要求用户提供用户名，通过列表或搜索功能定位他们当前的会话，并查看与会话有关的细节。各种系统日志也常常将令牌泄露给未授权方。虽然这种情况很少发生，但由于除了处在网络适当位置的窃听者之外，还有其他各种潜在的攻击者都能查阅这些日志，这种泄露通常会造成更严重的后果。

2014年漏洞报告平台乌云网披露了携程网安全漏洞信息，漏洞发现者称由于携程开启了用户支付服务接口的调试功能，支付过程中的调试信息可被任意黑客读取。

由于该漏洞存在，携程安全支付日志可遍历下载，导致大量用户银行卡信息泄露，包含持卡人姓名、身份证、银行卡号、卡CVV码、6位卡Bin等。所谓遍历是指沿着某条搜索路线，依次对树中每个结点均做一次且仅做一次访问。访问结点所做的操作依赖于具体的应用问题。

专家解释称，该漏洞之所以存在，是因为携程用于处理用户支付的安全支付服务器接口存在调试功能，将用户支付的记录用文本保存了下来。同时因为保存支付日志的服务器未做较严格的基线安全配置，存在目录遍历漏洞，导致所有支付过程中的调试信息可被任意黑客读取。

通常，这种监控和控制功能会泄露每个会话的令牌，而且，这种功能一般没有得到良好的保护，允许未授权用户访问当前会话令牌列表，因而劫持所有应用程序用户的会话。

会话令牌出现在系统日志中的另一个主要原因是应用程序使用URL查询字符串，而不是使用HTTP Cookies或POST请求主体作为令牌传输机制。例如，在Google上查询inurl:jsessionid即可确定数千个在以下URL中传送Java平台会话令牌（称作jsessionid）的应用程序。如果应用程序以这种方式传送会话令牌，它们的会话令牌就可能出现在各种未授权用户能够访问的系统日志中，例如：

（1）用户浏览器的日志；

（2）Web服务器日志；

（3）企业或ISP代理服务器日志；

（4）任何在应用程序主机环境中采用的反向代理的日志；

（5）应用程序用户通过单击站外链接访问的任何服务器的Referer日志。

上面描述的最后一种情况为攻击者提供一种截获应用程序会话令牌的非常有效的方法。例如，如果一个Web邮件应用程序在URL中传送会话令牌，那么攻击者就可以向应用程序的用户发送一封电子邮件，在里面包含一个连接到他控制的Web服务器的链接。如果任何用户访问这个链接（如单击它，或者他们的浏览器加载了包含在HTML格式的电子邮件中的图像），攻击者就会实时收到该用户的会话令牌。然后，攻击者只需在他的服务器上运行一段脚本，就可以劫持收到每一个令牌的会话，并执行某种恶意操作，如发送垃圾邮件、获取个人信息或修改密码等。

测试日志记录可能存在漏洞导致令牌泄露的方法如下。

（1）确定应用程序的所有功能，找出可查看会话令牌的任何日志或监控功能，查明谁能够访问这种功能，如管理员、任何通过验证的用户或匿名用户。

（2）确定应用程序使用URL中传送会话令牌的任何情况。可能应用程序通常以更加安全的方式传送令牌，但开发者在特定情况下使用URL来解决特殊难题。例如，Web应用程序与外部系统交互时通常会出现这种情况。

（3）如果应用程序在URL中传送会话令牌，尝试发现任何允许在其他用户查阅的页面中注入任意站外链接的应用程序功能，如公告牌、站点反馈、问与答等。如果可以，向受控制的一个Web服务器提交链接，等待一段时间，看Referer日志中是否收到任何用户的会话令牌。

（4）如果截获到任何会话令牌，尝试通过正常使用应用程序，而不是用截获的令牌代替自己的令牌来劫持用户的会话。可配置一些拦截代理服务器采用基于正则表达式（regex-based）的内容替换规则，自动修改HTTP Cookies之类的数据。

6.3.2 网络传送导致的令牌泄露

由于互联网早期并没有考虑到数据报文安全的问题，早期的理念都是基于进行通信的。现在随着网络兴起，互联网上慢慢有很多“犯罪团体”，用较低的犯罪成本通常是基于一个网络通信协议的一个小的漏洞来完成窃取、篡改、重播其他人的数据报文。

如果通过网络以非加密方式传送会话令牌，就会产生这方面的漏洞，使得处在适当位置的窃听者能够截获令牌并因此伪装成合法用户。窃听的适当位置包括用户的本地网络、用户所在的IT部门、用户的ISP、互联网骨干网、应用程序的ISP和运行应用程序组织的IT部门。处在上述任何一个位置，相关组织的授权人员和任何攻破相关基础架构的外部攻击者都可以截取会话令牌。

在最简单的情形中，应用程序使用一个非加密的HTTP连接进行通信。这使得攻击者能够拦截客户和服务器间传送的所有数据，包括登录证书、个人信息、支付细节等。这时，攻击者通常不必攻击用户的会话，因为攻击者已经可以查阅特权信息，并能够使用截获的证书登录，执行其他恶意操作。然而，有些时候，用户的会话仍然是攻击者的主要攻击目标。例如，如果截获的证书不足以执行第二次登录（如银行应用程序可能要求登录者提交在不断变化的物理令牌上显示的一串数字，或者用户PIN号码中的几个特殊数字），这时攻击者如果想执行任意操作，就必须劫持他窃听的会话。或者如果登录机制实施严格的审查，并且在每次成功登录后通知用户，那么攻击者可能希望避免自己登录，以尽可能保持活动的隐秘性。

在其他情况下，使用HTTPS保护关键客户——服务器通信的应用程序的会话令牌仍然可能在网络上遭到拦截。这种薄弱环节表现形式各异，其中有许多可能发生在应用程序使用HTTP Cookies作为会话令牌传输机制时。

一些应用程序在站点中预先通过验证的区域（如站点首页）使用HTTP，但从登录页面开始转换到HTTPS。然而，许多时候，应用程序在用户访问第一个页面时就给他发布一个会话令牌，并且在用户登录时也不修改这个令牌。最初并未通过验证的用户会话在登录后却被升级为通过验证的会话。在这种情况下，窃听者就可以在登录前拦截用户的令牌，等待用户转换到HTTPS进行通信（表示用户正在登录），然后尝试使用那个令牌访问一个受保护的页面（如“我的账户”）。

即使应用程序在用户成功登录后发布一个新令牌，并从登录页面开始使用HTTPS，但是，如果用户通过单击验证区域中的一个链接、使用“后退”按钮或者直接输入URL，重新访问一个预先验证的页面（如“帮助”或“关于”页面），用户通过验证的会话令牌仍有可能泄露。

与前面的情况稍有不同，应用程序可能在用户单击登录链接后转换到HTTPS。然而，如果用户对URL进行相应修改，应用程序仍然接受通过HTTP进行登录。这时，处在适当位置的攻击者就可以修改站点预先通过验证的区域返回的页面，使登录链接指向一个HTTP页面。即使应用程序在用户成功登录后发布一个新令牌，如果攻击者已成功将用户的链接降级为HTTP，他仍然能够拦截这个令牌。

一些应用程序对应用程序内的全部静态内容（如图像、脚本、样式表和页面模板）使用HTTP。如果出现这种行为，用户的浏览器将显示一条警告消息。如前所述，如果用户的浏览器通过HTTP访问一个资源，并使用这个令牌通过HTTPS访问站点中受保护的非静态区域，攻击者就能拦截该用户的会话令牌。

即使应用程序在每一个页面（包括站点中未通过验证的区域和静态内容）都使用HTTPS，有些情况下，用户的令牌仍然通过HTTP传送。如果攻击者能够以某种方式诱使用户通过HTTP提出一个请求，那么用户就可能在这个过程中提交令牌。这时，攻击者可以采用的攻击手段包括在一封电子邮件或即时消息中给用户发送一个URL、在他控制的一个Web站点中插入一个自动加载的链接，或者使用可单击的标题广告。

测试网络传送可能存在漏洞导致令牌泄露的方法如下。

（1）以正常方式访问应用程序，从第一个进入点（“起始”URL）开始，接着是登录过程，然后是应用程序的全部功能。记录每一个被访问的URL以及收到新会话令牌的每种场合。特别注意登录功能及HTTP与HTTPS通信之间的转换。可以使用网络嗅探器（如Wireshark）手动或使用拦截代理服务器中的日志功能部分自动完成这一任务。

图6-7表示使用Wireshark软件捕获网络中传输的HTTP报文段。

1 单击软件左上角捕获按钮开始捕获。

2 在过滤器输入框中输入“http”，只捕获http报文信息。

（2）如果应用程序使用HTTP Cookies传送会话令牌，那么应确认其是否设置了secure标记，防止它们通过非加密连接传送令牌。

（3）在正常使用应用程序的情况下，确定会话令牌是否通过非加密连接传送。如果确实如此，应将其视为易于受到拦截。

（4）如果起始页面使用HTTP，然后在登录和站点中通过验证的区域转换到HTTPS，确认应用程序是否在用户登录后发布一个新令牌，或者在使用HTTP阶段传送的令牌是否仍被用于追踪用户通过验证的会话。同时确认，如果对登录URL进行相应修改，应用程序是否接受通过HTTP登录。

（5）即使应用程序在每一个页面使用HTTPS，确认服务器是否还监听80端口，通过它运行任何服务或内容。如果是这样，直接使用通过验证的会话访问所有HTTP URL，确认会话令牌是否被传送。

（6）如果通过HTTP将通过验证会话的令牌传送给服务器，确认该令牌是否继续有效，或者立即被服务器终止。

6.3.3 会话管理机制存在各种漏洞

由于应用程序在将生成和处理的会话令牌与令牌所属的用户会话之间进行对应的过程中存在薄弱环节，会话管理机制因此存在各种常见的漏洞。

最简单的漏洞是允许给同一个用户账户同时分配几个有效的令牌。在几乎每一个应用程序中，任何用户都没有正当理由在任何指定的时间拥有几个会话。当然，用户常常会终止一个处于活动状态的会话，再开始一个新会话，如关闭浏览器窗口或转换到另一台计算机上。但是，如果一名用户明显同时在使用两个不同的会话，这通常表示出现了安全问题：要么是用户将证书泄露给了另一方，要么是攻击者通过其他某种途径获得了他们的证书。无论发生哪一种情况，都不应允许并行会话，因为它可使用户能够持续执行任何非法操作，也因为它允许攻击者使用截获的证书，却不存在被检测出来的风险。

应用程序使用“静态”令牌是一种相对较为特殊的缺陷。这些“令牌”看似会话令牌，最初表现的功能和会话令牌一样，但实际并非如此。在这些应用程序中，每名用户都分配有一个令牌，并且用户每次登录，都收到相同的令牌。无论用户是否已经登录并获得令牌，应用程序都应将该令牌视为有效令牌。这种应用程序实际上是对会话的整体概念以及这样做有助于管理和控制应用程序访问存有误解。有些时候，应用程序这样运作，是为了执行设计上存在缺陷的“记住我”功能，并因此将静态令牌保存在一个持久性Cookies中（请参阅第6章了解相关内容）。有时，令牌本身易于受到预测攻击，致使这种漏洞造成更加严重的后果，因为一次成功的攻击不仅能够攻破当前登录用户的会话，如果时间允许，还能攻破所有注册用户的账户。

测试会话管理机制可能存在漏洞导致令牌泄露的方法如下。

（1）用相同的用户账户从不同的浏览器进程或从不同的计算机两次登录应用程序，确定这两次会话是否都处于活动状态。如果是，表示应用程序支持并行会话，使得攻破其他用户证书的攻击者能够利用这些证书，而不会有被检测出来的风险。

（2）用相同的用户账户从不同的浏览器进程或从不同的计算机几次登录和退出应用程序，确定应用程序在每次登录时是发布一个新会话令牌，还是发布相同的令牌。如果每次发布相同的令牌，那么应用程序根本没有正确使用令牌。

（3）如果令牌明显包含某种结构和意义，设法将标识用户身份的成分与无法辨别的成分区分开来。尝试修改所有与用户有关的令牌成分，使其指向其他已知的应用程序用户，确定修改后的令牌是否被应用程序接受，以及能够让攻击者伪装成哪名用户。

6.3.4 不能提供有效会话终止功能

在网络中，客户端与服务器之间通过登录进程开始会话，通过退出进程结束会话，在TCP/IP环境下，每一个应用层协议都有自己开始和接收会话的语法。例如，FTP协议中客户端向服务器发送USER命令并跟随用户名，然后发送PASS命令和密码；结束时，FTP程序发送QUIT命令。这些虽说是FTP客户端程序和它们完成的会话层指定的功能，作为TCP/IP协议簇一部分的其他应用程序，都有与FTP类似的会话开始和结束的命令来完成会话层的功能。在登录过程中，有一个进程决定用户可以登录的时间和可以访问的资源，决定哪些工作站可以登录。当用户退出资源访问时，文件关闭，支持会话的网络进程中断。会话结束，在整个过程中，客户端发出登录和退出会话过程，服务器处理客户端相应的请求。

由于两方面的原因，正确终止会话非常重要。首先，尽可能缩短一个会话的寿命可降低攻击者截获、猜测或滥用有效会话令牌的可能性；其次，如果用户不再需要现有会话，终止会话为用户提供一种使其失效的途径，在进一步降低上述可能性的同时，在某种程度上确保共享计算环境中会话的安全。会话终止功能的主要缺陷大都与无法满足这两个关键目标有关。

一些应用程序并不实施有效的会话终止功能，会话一旦建立，它在收到最后请求后的许多天内也仍然有效，直到服务器最终将其清除。即使令牌存在某种非常难以利用的缺陷（如确定每个有效令牌需要100000次猜测），攻击者仍然能够截获最近访问应用程序的每一名用户的令牌。甚至有些时候，应用程序根本不执行退出功能。用户没有办法要求应用程序终止他们的会话。退出功能实际上并不能帮助服务器终止会话。即使服务器从用户的浏览器中删除令牌（如通过发布一个清空令牌的Set-Cookies指令），如果用户继续提交这个令牌，服务器仍然接受它。

最糟糕的情况：当用户单击“退出”按钮时，应用程序并不与服务器通信，因此服务器不采取任何行动。相反，应用程序执行一段客户端脚本清空用户的Cookies，在随后的请求中将用户返回到登录页面。访问这个Cookies的攻击者就能使用会话，好像用户从未退出一样。

测试会话终止功能可能存在漏洞导致令牌泄露的方法如下。

（1）不要掉入陷阱，检查应用程序对客户端令牌执行的操作（如通过一个新的Set-Cookies指令、客户端脚本或者终止时间属性令Cookies失效）。在客户浏览器内对令牌执行的任何操作并不能终止会话。相反，调查服务器端是否执行会话终止操作。

首先登录应用程序获得一个有效令牌，然后不使用这个令牌，等待一段时间后，使用这个令牌提交一个访问受保护页面的请求。如果该页面正常显示，表示令牌仍然处于活动状态。

最后使用反复试验的方法确定会话终止超时时间，或者一个令牌在最后一次使用它提交请求几天后是否仍被使用。可配置Burp Stuite递增连续请求之间的时间间隔，自动完成这项任务。

（2）确定是否存在退出功能，用户是否能够使用这一功能。如果不能，表示用户更易于受到攻击，因为他们没有办法让应用程序终止会话。

（3）如果应用程序提供退出功能，测试其效率。退出后，尝试重新使用原有的令牌，确定其是否仍然有效。如果令牌仍然有效，那么即使用户已经“退出”，也依然易于受到会话劫持攻击。

6.3.5 向应用程序客户端用户发动攻击

攻击者可以使用其他针对用户的攻击，以不同的方式劫持用户的会话。这包括实施会话固定攻击，即攻击者向一名用户发送一个已知的会话令牌，等待他们登录，然后劫持他们的会话，以及跨站点请求伪造攻击，其中攻击者从他控制的一个Web站点向应用程序提出一个专门设计的请求，由于用户的浏览器会随同这个请求一起自动提交用户当前的Cookies，攻击者因此会获得用户的Cookies。

测试应用程序客户端可能存在漏洞导致令牌泄露的方法如下。

（1）确定应用程序中存在的任何跨站点脚本漏洞，看是否可以利用这些漏洞截获其他用户的会话令牌。

（2）如果应用程序向未通过验证的用户发布令牌，就会获得一个令牌并进行一次登录。如果应用程序在攻击者登录后并不发布一个新令牌，就表示它易于受到会话固定攻击。

（3）即使应用程序并不向未通过验证的用户发布会话令牌，仍然会通过登录获得一个令牌，然后返回登录页面。如果应用程序“愿意”返回这个页面，即使攻击者已经通过验证，那么也可以使用相同的令牌以另一名用户的身份提交另一次登录。如果应用程序在第二次登录后并不发布一个新令牌，表示它易于受到会话固定攻击。

（4）确定应用程序会话令牌的格式。用一个捏造的格式有效的值修改令牌，然后尝试使用它登录。如果应用程序允许使用一个捏造的令牌建立一个通过验证的会话，表示它易于受到会话固定攻击。

（5）如果应用程序并不支持登录功能，但处理敏感数据（如个人信息和支付细节），并在提交后显示这些信息（如在“确认订单”页面上），那么使用前面的3种测试方法尝试访问显示敏感数据的页面。如果在匿名使用应用程序期间生成的令牌可用于获取用户的敏感信息，那么应用程序就易于遭受会话固定攻击。

（6）如果应用程序完全依靠HTTP Cookies传送会话令牌，它很可能容易受到跨站点请求伪造（XSRF）攻击。首先登录应用程序，然后从另一个应用程序的一个页面向应用程序提出一个请求，确认它是否会提交用户的令牌。设法确定所有参数可由攻击者提前决定的应用程序敏感功能，利用这种缺陷在目标用户的权限下执行未授权操作。