成功验证的用户常常得到某种类型的安全令牌,这样他们在应用的已验证部分中浏览时不需要重新输入凭据。这种机制的一个令人遗憾的副作用是可以通过恶意重放捕获的令牌绕过验证,这种现象有时被称作会话劫持。
Web应用一般通过保存在浏览器Cookie中的会话ID来跟踪已验证的用户会话。我们将在本小节中简短地讨论常见的猜测或者获得基于Cookie的会话ID的机制。更多关于针对验证和会话状态的攻击的信息,请参见第5章。
会话ID攻击
获得会话ID的两种基本技术是预测和暴力法。较旧的Web应用往往使用容易猜测、有时候甚至是顺序的会话标识符。使用不安全的算法或者没有足够信息量的伪随机码生成器生成的非顺序会话ID可以使用数学技术如统计预测进行预测。虽然现在所有主要的应用服务器都试图使用不可预测的会话标识符,但是偶然会发现针对广泛使用的流行技术的新型攻击。例如,2010年3月,安全研究人员Andreas Bogk揭露了PHP平台会话ID中的一个漏洞——生成功能可能导致可用会话ID池缩小到可以使用暴力会话攻击的程度。这说明了一点,在安全中没有什么是理所当然的,最好的方法始终是纵深防御策略,并着眼于基础。
对会话ID的暴力攻击包括使用所有可能的会话ID发出数千个请求,希望正确地猜中ID。需要的请求数量取决于会话ID的密钥空间。因此,这种类型攻击的成功率可以根据会话ID的大小和密钥空间来计算。
试图对流行Web应用服务器(如Java、PHP、ASP.NET)中使用的会话ID进行暴力攻击毫无意义,因为这些平台生成的会话ID的尺寸非常大。但是,对生成自定义会话ID或者其他验证令牌的应用来说,这种攻击可能产生有用的结果。
另一种针对会话ID的攻击随着多年来会话ID安全的增强而基本被废弃。这种攻击被称作会话完成攻击(Session fixation)。会话完成攻击中,攻击者可以预先设置应用服务器在后续用户验证中使用的会话ID。因为攻击者设置该值,使用预设会话ID进行验证的用户将立即暴露在会话劫持攻击之下。虽然这种漏洞比起多年前要少见,但是应用评估人员必须知道这种漏洞,并且必须知道如何在Web应用中识别它。更多关于这种攻击技术的信息请参考第5章中的“会话完成”小节和“参考与延伸阅读”。
提示 iDefense.com的David Endler编写了会话ID实现中许多弱点的详细说明。链接可以在本章结尾处的“参考与延伸阅读”中找到。
入侵cookie
cookie常常包含与验证相关的敏感数据。如果cookie包含密码或者会话标识符,窃取这个cookie就可能是对网站的非常成功的攻击。用于窃取cookie的常见技术有多种,最流行的是脚本注入和窃听。我们将在第6章中讨论脚本注入技术(也称跨站脚本)。
离线对cookie进行逆向工程也被证明是非常有力的攻击。最好的办法是收集使用不同输入的cookie示例,查看cookie改变的方式。你可以在不同的时间使用不同的账户进行验证来做到这一点。思路是查看cookie如何根据时间、用户名、访问权限等变化。比特翻转(Bit-flipping)攻击采用暴力方法,有条理地修改各位,查看cookie是否仍然有效,是否获得不同权限。我们将在第5章更详细地研究cookie攻击。在着手攻击cookie值之前,应该注意,首先要理解使用的任何编码,以及为了成功地攻击是否需要对cookie进行解码。应用开发人员常见的错误是在需要加密时使用编码格式如Base 64。这种错误有时候见于为了性能原因将角色信息缓存在cookie中的应用。因为Base64很容易解码,攻击者可以解码、修改和重新编码cookie值,可能改变分配的角色,获得应用的未授权访问。Burp web代理这样的工具对操作cookie和使用常见算法编码、解码和计算散列值等均有很好的支持。
令牌回放攻击对策
窃听是盗取安全令牌(如cookie)的最简便手段。应该使用SSL或者其他合适的会话保密技术对抗窃听攻击。
除了在线窃听之外,要知道常用的Web客户还有许多安全问题,可能将你的安全令牌暴露给恶意的客户端软件或者跨站脚本操纵(详见第9章)。
一般来说,最好的方法是使用应用服务器提供的会话标识符。但是,如果你需要建立自己的标识符,应该设计无法预测以及无法使用暴力方法攻击的令牌。例如,使用足够信息量的随机数生成器来生成会话标识符。除此之外,为了预防暴力攻击,使用无法用暴力法攻击的足够大密钥空间的会话标识符(目前的技术大约是128位)。记住,使用伪随机码生成器时你必须考虑一些问题。例如,将4个随机生成的32位整数组合起来创建一个128位会话标识符,不如使用加密的安全PRNG随机生成一个128位值安全。4个样本的会话标识符很难阻止暴力攻击。
你还应该实现安全令牌如cookie和会话ID的完整性检查,以防止客户端或者传输中的篡改。可以使用散列消息验证代码(HMAC)或者加密整个cookie值来阻止篡改。
一般来说,即使你实现了强大的保密措施和完整性保护机制,也不建议在客户端安全令牌中存储敏感数据。