目录
会话令牌处理中的薄弱
简介：
不管应用程序如何确保它生成的令牌不包含任何有意义的信息，并且很难加以分析或预测，但如果生成令牌后不对其小心处理，会话机制仍然易于受到各种攻击。
如果以某种方式将令牌透露给攻击者，即使攻击者无法预测令牌， 也仍然能够劫持用户的会话。应用程序以不安全的方式处理令牌， 致使令牌易于遭受多种攻击
1.1、在网络上泄露令牌
简述：
1、如果通过网络以非加密方式传送会话令牌， 就会产生这方面的漏洞，允许处在适当位置的窃听者能够截获令牌并因此伪装成合法用户。窃听的适当位置包括用户的本地网络、用户所在的IT部门、用户的ISP、因特网骨干网、应用程序的ISP和运行应用程序组织的IT部门。处在上述任何一个位置， 相关组织的授权人员和任何攻破相关基础架构的外部攻击者都可以截取会话令牌
在最简单的情形中， 应用程序使用一个非加密的HTTP连接进行通信。这使攻击者能够拦截客户端和服务器间传达的所有数据， 包括登录证书、个人倌息、支付细节等。攻击者通信不必攻击用户的会话， 因为攻击者已经可以查阅特权信息， 并能够使用截获的证书登录， 从而执行其他恶意操作
2、有时，用户的会话仍然是攻击者的主要攻击目标。如果截获的证书不足以执行第二次登录（如银行应用程序可能要求登录者提交在不断变化的物理令牌上显示的一串数字， 或者用户PIN号码中的几个特殊数字）这时攻击者如果想执行任意操作，就必须劫持他窃听的会话。或者如果登录机制实施严格的审查，并且在每次成功登录后通知用户， 那么攻击者可能希望避免自己登录，以尽可能保持活动的隐秘性。
3、其他情况下， 使用HTTPS保护关键客户端－服务器通信的应用程序的会话令牌仍然可能在网络上遭到拦截。这种薄弱环节表现形式各异， 其中有许多可能发生在应用程序使用HTTP cookie作为会话令牌传输机制时
一些应用程序在登录阶段选择使用HTTPS保护用户证书的安全， 但在用户会话的其他阶段转而使用HTTP，许多Web邮件应用程序以这种方式运作，在这种情况下窃听者无法拦截用户的证书， 但仍然可以截获会话令牌。Firefox的插件Firesheep工具会让这一过程变得轻而易举
一些应用程序在站点中预先通过验证的区域（如站点首页）使用HTTP， 但从登录页面开始转换到HITPS。应用程序在用户访问第一个页面时就给他发布一个会话令牌， 并且在用户登录时也不修改这个令牌。最初并未通过验证的用户会话在登录后却被升级为通过验证的会话。在这种情况下， 窃听者就可以在登录前拦截用户的令牌，等待用户转换到HTTPS进行通信（表示用户正在登录）然后尝试使用那个令牌访问一个受保护的页面
即使应用程序在用户成功登录后发布一个新令牌， 并从登录页面开始使用HTTPS，但如果用户通过单击验证区域中的一个链接、使用 "后退" 按钮或者直接输人URL, 重新访问一个预先验证的页面（如"帮助" 、"关于" 页）， 用户通过验证的会话令牌仍有可能泄露
与前面的情况稍有不同， 应用程序可能在用户单击登录链接后转换到HTTPS。但如果用户对URL进行相应修改， 应用程序仍然接受通过HTTP进行登录。处在适当位置的攻击者就可以修改站点预先通过验证的区域返回的页面， 使登录链接指向一个HTTP页面。即使应用程序在用户成功登录后发布一个新令牌， 如果攻击者已成功将用户的链接降级为HTTP，仍然能够拦截这个令牌
一些应用程序对应用程序内的全部静态内容（如图像、脚本、样式表和页面模板）使用HTTP。如果出现这种行为， 用户的浏览器将显示一条警告消息。当浏览器显示警告时， 它已经通过HTTP获取了相关数据项， 因而已经传送了会话令牌。浏览器显示警告是为了让用户拒绝处理已通过HTTP接收到并因此可能受到污染的响应数据。如前所述， 如果用户的浏览器通过HTTP访问一个资源， 并使用这个令牌通过HTTPS访问站点中受保护的非静态区域， 攻击者就能拦截该用户的会话令牌
即使应用程序在每一个页面（包括站点中未通过验证的区域和静态内容）都使用HTTPS，有些情况下， 用户的令牌仍然通过HTTP传送。如果攻击者能够以某种方式诱使用户通过HTTP提出一个请求（或者是请求相同服务器上运行的HTTP服务， 或者是访间http//server:443/)，那么用户就可能在这个过程中提交令牌。这时， 攻击者可以采用的攻击手段包括在一封电子邮件或即时消息中给用户发这一个URL， 在他控制的一个Web站点中插人一个自动加载的链接， 或者使用可单击的横幅广告。
过程：
1、以正常方式访问应用程序， 从第一个进入点( “起始“ URL)开始， 接着是登录过程，然后是应用程序的全部功能。记录每一个被访问的URL以及收到新会话令牌的每种场合。特别注意登录功能及HTTP与HTTPS通信之间的转换。可以使用网络嗅探器（如Wireshark）手动或使用拦截代理服务器中的日志功能部分自动完成这一任务（遍历应用程序， 确认收到新会话令牌的位置）
2、如果应用程序使用HTTPcookie传送会话令牌， 那么应确认其是否设置了secure标记，防止它们通过非加密连接传送令牌
3、在正常使用应用程序的情况下， 确定会话令牌是否通过非加密连接传送。如果确实如此， 应将其视为易于受到拦截。
4、如果起始页面使用HTTP，然后在登录和站点中通过验证的区域转换到HTTPS,确认应用程序是否在用户登录后发布一个新令牌， 或者在使用HTTP阶段传送的令牌是否仍被用于追踪用户通过验证的会话。同时确认， 如果对登录URL进行相应修改， 应用程序是否接受通过HTTP登录
5、即使应用程序在每一个页面使用HTTPS，确认服务器是否还监听80端口，通过它运行任何服务或内容。如果是这样， 直接使用通过验证的会话访问所有HTTP URL，确认会话令牌是否被传送。
6、如果通过HTTP将通过验证会话的令牌传送给服务器， 确认该令牌是否继续有效， 或者立即被服务器终止
1.2、在日志中泄漏令牌
简述：
1、除在网络通信中明文传送会话令牌外， 各种系统日志也常常将令牌泄露给未授权方。虽然这种情况很少发生， 但由于除了处在网络适当位置的窃听者之外，还有其他各种潜在的攻击者都能查阅这些日志． 这种泄露通常会造成更严项的后果
许多应用程序为管理员和其他支持人员提供监控和控制应用程序运行时状态（包括用户会话）的功能。例如，帮助用户解决疑难的服务台工作人员可能会要求用户提供用户名、通过列表或搜索功能定位他们当前的会话， 并查看与会话有关的细节。或者管理员可能会在调查一起违反安全事件的过程中查询最近会话的日志记录。这种监控和控制功能会泄漏每个会话的令牌。这种功能一般没有得到良好的保护， 允许未授权用户访问当前会话令牌列表， 因而劫持所有应用程序用户的会话
2、会话令牌出现在系统日志中的另一个主要原因是应用程序使用URL查询字符串， 而不是使用HTTP cookie或POST请求主体作为令牌传输机制。例如， 在Google上查询inurl:jsessionid即可确定数千个URL中传送Java平台会话令牌（称作jsessionid)的应用程序
如果应用程序以这种方式传送会话令牌， 它们的会话令牌就可能出现在各种未授权用户能够访问的系统日志中， 如：用户浏览器的日志、Web服务器日志、企业或ISP代理服务器日志、任何在应用程序主机环境中采用的反向代理的日志、应用程序用户通过单击站外链接访问的任何服务器的Referer日志
3、即使整个应用程序都使用HTTPS，这些漏洞仍有可能出现。
上面描述的最后一种情况为攻击者提供了一种截获应用程序会话令牌的非常有效的方法。例如，如果一个Web邮件应用程序在URL中传送会话令牌， 那么攻击者就可以向应用程序的用户发送一封电子邮件， 在里面包含一个连接到他控制的Web服务器的链接。如果任何用户访问这个链接（如单击它， 或者他们的浏览器加载了包含在HTML格式的电子邮件中的图像），攻击者就会实时收到该用户的会话令牌。然后， 攻击者只需在他的服务器上运行一段脚本， 就可以劫持每一个令牌的会话， 并执行某种恶意操作，如发送垃圾邮件、获取个人信息或修改密码
过程：
1、确定应用程序的所有功能， 找出可查看会话令牌的任何日志或监控功能。查明谁能够访问这种功能， 例如管理员、任何通过验证的用户或匿名用户。
2、确定应用程序使用URL中传送会话令牌的任何情况。可能应用程序通常以更加安全的方式传送令牌， 但开发者在特定情况下使用URL来解决特殊难题。例如， Web应用程序与外部系统交互时通常会出现这种情况。
3、如果应用程序在URL中传送会话令牌， 尝试发现任何允许在其他用户查阅的页面中注入任意站外链接的应用程序功能， 如公告牌、站点反馈、问与答等功能。如果可以，向一个受控制的Web服务器提交链接， 等待一段时间，看Referer日志中是否收到任何用户的会话令牌
4、如果截获到任何会话令牌， 尝试通过正常使用应用程序，而不是用截获的令牌代替自己的令牌来劫持用户的会话。可以通过拦截服务器返回的下一个响应，并使用截获的cookie值添加自己的Set-Cookie消息头， 以实现这一目的。在Bp中，可以应用一个Suite范围的配置， 在所有指向目标应用程序的请求中设置一个特殊cookie,以便测试期间在不同的会话之间轻松切换。
5、如果截获到大量令牌， 并且通过劫持用户的会话可以访问他们的敏感数据（如个人资料、支付信息或用户密码），使用自动技巧获得想要的
597
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
