参考: The Web Application Hacker’s Handbook Chapter 7
web应用程序必须采取的防御措施必须采取防止对其会话管理机制的攻击,对应于影响这些机制的两大类脆弱性。为了以安全的方式执行会话管理,应用程序必须以一种健壮的方式生成其令牌,并必须在他们的生命周期中保护这些令牌,从创建到处理。
1.Generate Strong Tokens
用于在连续请求之间重新识别用户的令牌,应该以一种不提供任何范围的方式生成,这对攻击者来说,从应用程序中获得一个大的标记样本,以预测或推断给其他用户的令牌。
最有效的令牌生成机制是:
- 使用一组非常大的可能值
- 包含强大的伪随机数来源，确保令牌在可能的值范围内均匀且不可预测地分布
原则上,任何任意长度和复杂性的项目都可以通过使用野蛮的时间和资源来猜测。设计一个强大的令牌的机制的目标是,一个确定的攻击者在带宽和处理资源的大量带宽上不太可能在其有效性的生命周期内猜测一个有效的令牌。
令牌应该由服务器使用的一种标识符来定位相关的会话对象,以处理用户的请求。令牌应该不包含任何意义或结构,无论是在编码或混淆的层中。关于会话的所有者和状态的所有数据都应该存储在会话对象的服务器上,会话令牌对应于此。
在选择随机性的来源时要小心。开发人员应该意识到,它们提供的各种来源可能会显著不同。有些,比如java.util。随机的,对于许多目的都是非常有用的,在那里需要改变输入的来源。但它们可以在一项输出的基础上,以完美的确定性在向前和逆向的方向上进行推断。开发人员应该研究在不同可用的随机性来源中使用的实际算法的数学属性,并应该阅读有关推荐使用不同api的相关文档。一般来说,如果一个算法没有被明确地描述为加密安全,那么它应该被假定是可预测的。
NOTE
一些高强度的随机性来源需要一些时间来返回它们的输出序列的下一个值,因为它们采取的步骤可以获得足够的熵(如系统事件)。因此,它们可能无法快速交付值,以便为一些高容量的应用程序生成标记。
除了选择最可靠的随机性源之外,一个好的实践是将熵源介绍为一些关于令牌正在生成的个人请求的信息。该信息可能不是唯一的请求,但它可以有效地减轻在使用的核心伪包数字生成器中的任何弱点。以下是一些可能被合并的信息示例:
- 收到请求的源IP地址和端口号
- 请求中的用
User-Agent头 - 请求毫秒的时间
包含这个熵的一个非常有效的公式是构造一个字符串,它连接了一个伪包号、一个特定的请求-特定数据,以及一个只在服务器上被知道的秘密字符串,并在每个重新启动时重新生成。然后使用这个字符串(例如,在本文的时候使用SHA-256)来生成一个可管理的fi xl长度的字符串,可以作为标记使用。(将最变量项放置在哈希输入的开始时,将“雪崩”效果最大化。)
TIP 选择了一个生成会话令牌的算法,一个有用的“思想实验”就是想象你的伪性源被打破,并且总是返回相同的值。在这种情况下,如果一个攻击者从应用程序中获得了一个大样本,它能够将向其他用户发布的令牌标记吗?使用这里描述的公式,一般来说,这是极不可能的,即使完全了解使用的算法。源IP、端口号、用户代理头和请求时间会产生大量的熵。即使完全了解这些,攻击者也不能在不知道服务器使用的秘密字符串的情况下生成相应的令牌。
2.Protect Tokens Throughout Their Life Cycle
现在,您已经创建了一个强大的令牌,其价值不能被预测,这个令牌需要在其生命周期中被保护,从创建到处理,以确保它不会被公开,而不是它发布的用户:
- 令牌只能在HTTPS上传输。在cleartext中传递的任何标记都应该被视为污染——即不提供用户身份的保证。如果HTTP cookie被用来传输令牌,那么应该将这些cookie作为安全工具,以防止用户的浏览器在HTTP上传输它们。如果可行,HTTPS应该用于应用程序的每一页,包括静态内容,如帮助页面、图像等。如果这是不需要的,而且还实现了HTTP服务,那么应用程序应该重定向任何对敏感内容的请求(包括登录页面)到HTTPS服务。诸如帮助页面这样的静态资源通常不敏感,可以在没有任何身份验证的会话的情况下访问。因此,使用cookie范围指令可以支持使用安全cookie,以防止在请求这些资源时提交令牌。
- 会话标记不应该在URL中传输,因为这为会话固定攻击和在许多日志机制中出现的令牌提供了一个简单的工具。在某些情况下,开发人员使用这种技术来在没有cookie的浏览器中实现会话。然而,更好的实现方法是使用POST请求进行所有的导航,并在HTML表单的隐藏的fi方向上存储令牌。
- 必须执行注销功能。这应该处理服务器上所持有的所有会话资源,并使会话令牌失效。
- 会话过期应在适当的不活动时间(如10分钟)后实施。这应该导致与用户显式退出的行为相同。
- 应该避免并发登录。每次用户登录时,应该发布一个不同的会话令牌,而属于用户的任何现有会话都应该被处理,就像她已经退出了。当发生这种情况时,可以将旧的令牌存储一段时间。任何使用令牌接收的后续请求都应该将安全警报返回给用户,说明会话已经终止,因为她从不同的位置登录。
- 如果应用程序包含任何允许会话令牌被查看的管理或诊断功能,那么该功能应该对未经授权的访问进行有力的防御。在大多数情况下,不需要这个功能来显示实际的会话令牌。相反,它应该包含关于会话所有者的详细细节,以获得任何支持和诊断任务,而不泄露用户提交的会话令牌,以确定她的会话。
- 应该尽可能严格地设置应用程序的会话cookie的域和路径范围。范围过于宽松的cookie通常是由缺乏信任的web应用程序平台或web服务器生成的，而不是由应用程序开发人员自己生成的。不应该通过包含在应用程序cookie范围内的域名或URL路径访问其他web应用程序或不受信任的功能。应该特别注意用于访问应用程序的域名的任何现有子域。在某些情况下，为了确保不出现此漏洞，可能需要修改组织中使用的各种应用程序所采用的域和路径命名方案。
应采取具体措施，保护会话管理机制免受应用程序的用户可能发现自己成为下列各种攻击的目标:
- 应该严格审计应用程序的代码库，以识别和删除任何跨站点脚本漏洞(参见第12章)。大多数此类漏洞可以被用来攻击会话管理机制。特别是，存储的(或二级的)XSS攻击通常可以被利用来击败针对会话误用和劫持的所有可能的防御。
- 不应该接受服务器不识别的用户提交的任意令牌。应该立即在浏览器中取消令牌，并将用户返回到应用程序的开始页面。
- 跨站点请求伪造和其他会话攻击可能会变得更加困难，因为在执行关键操作(如资金转移)之前，需要进行两步确认和/或重新验证。
- 跨站点请求伪造攻击可以通过不完全依赖HTTP cookie来传输会话令牌来进行防御。使用cookie机制会引入此漏洞，因为无论什么原因导致请求发生，浏览器都会自动提交cookie。如果标记总是以HTML表单的隐藏方式传输，那么攻击者无法创建提交将导致未授权操作的表单，除非他已经知道标记的值。在这种情况下，他可以简单地执行一个简单的劫持攻击。每个页面标记还可以帮助防止这些攻击(参见下面的部分)。
- 在成功的身份验证之后，应该始终创建一个新的会话，以减轻会话fi攻击的影响。在应用程序不使用身份验证但允许提交敏感数据的情况下，fi攻击造成的威胁更难解决。一种可能的方法是保持提交敏感数据的页面的顺序尽可能短。然后，您可以在这个序列的fi rst页面上创建一个新会话(必要时，从现有会话复制任何需要的数据，例如购物车的内容)。或者，您可以使用每个页面的令牌(在下一节中描述)来防止知道fi rst页面中使用的令牌的攻击者访问后续页面。除非有特别需要，否则不应向用户显示个人资料。即使在需要这样做的地方(例如显示地址的“确认订单”页面)，信用卡号和密码等敏感项也不应该显示给用户，而应该始终在应用程序的响应源中进行屏蔽。
2.1 每页的令牌(Per-Page Tokens)
可以实现对会话的细粒度控制，并且可以通过使用会话标记之外的每个页面标记使许多类型的会话攻击变得更加困难或不可能。在这里，每当用户请求应用程序页面(例如，与图像相反)并通过cookie或HTML表单的隐藏字段传递给客户端时，都会创建一个新的页面标记。每次用户发出请求时，除了对主会话令牌进行常规验证外，还根据最后发出的值对页面令牌进行验证。在不匹配的情况下，整个会话将被终止。Internet上许多对安全性要求最高的web应用程序(如在线银行)使用每个页面的令牌来为其会话管理机制提供更多的保护，如图7-12所示。
每个页面标记的使用确实对导航施加了一些限制(例如，对后退和前进按钮以及多窗口浏览的使用)。但是，它可以有效地防止会话攻击，并确保合法用户和攻击者同时使用被劫持的会话，在双方都发出一个请求之后，这种攻击会很快被阻止。每个页面标记还可以用来跟踪用户在应用程序中的位置和移动。它们还可以用来检测从定义的序列之外访问函数的尝试，帮助防止某些访问控制缺陷(参见第8章)。
3.Log, Monitor, and Alert
应用程序的会话管理功能应该与其日志、监视和警报机制紧密集成，以提供有关异常活动的适当记录，并使管理员能够在必要时采取防御行动:
- 应用程序应该监视包含无效令牌的请求。除了在最可预测的情况下，尝试猜测向其他用户发出的令牌的成功攻击通常涉及发出大量包含无效令牌的请求，在应用程序日志中留下明显的标记。
- 对会话令牌的强力攻击很难完全阻止，因为无法禁用任何特定的用户帐户或会话来阻止攻击。一种可能的操作是在接收到大量包含无效令牌的请求时阻塞源IP地址一段时间。但是，当一个用户的请求来自多个IP地址(例如AOL用户)时，或者当多个用户的请求来自同一个IP地址(例如代理或防火墙后执行网络地址转换的用户)时，这可能是无效的。
- 即使不能实时有效地阻止对会话的暴力攻击，保留详细的日志并向管理员发出警报也能使他们调查攻击并在可能的地方采取适当的行动。
- 在可能的情况下，应该对与会话相关的异常事件(如并发登录或明显的劫持(使用每个页面标记检测到)向用户发出警报。即使可能已经发生了妥协，这也使用户能够检查是否发生了任何未经授权的操作，如资金转移。
3.1 反应性会话终止(Reactive Session Termination)
会话管理机制可以作为针对应用程序的许多其他攻击的高效防御手段。一些对安全至关重要的应用程序(如网上银行)在用户每次提交异常请求时都非常主动地终止其会话。 例如，任何请求包含修改过的隐藏HTML表单字段或URL查询字符串参数，任何请求包含与SQL注入或跨站点脚本攻击相关的字符串，以及任何用户输入通常会被客户端检查(如长度限制)阻止。
当然，使用此类请求可能被利用的任何实际漏洞都需要从源头上加以解决。但是，强制用户在每次提交无效请求时都进行重新身份验证，会大大降低应用程序的漏洞探测速度，即使在使用了自动化技术的情况下也是如此。如果残留的漏洞仍然存在，那么它们被该领域的任何人发现的可能性要小得多。
在实现这种防御的地方，还建议为了测试的目的，可以很容易地关闭它。如果应用程序的合法渗透测试以与真实的攻击者相同的方式变慢，那么它的有效性将显著降低。此外，与没有该机制相比，该机制的存在很可能会导致在生产代码中留下更多的漏洞。
HACK STEPS
如果您正在攻击的应用程序使用这种防御措施，您可能会发现探测应用程序的许多常见漏洞是非常耗时的。每次测试失败后都需要登录并重新导航到您正在查看的应用程序，这种麻木的需求会很快让您放弃。
在这种情况下，您通常可以使用自动化来处理这个问题。当使用Burp Intruder执行攻击时，您可以使用获取Cookie特性在发送每个测试用例之前执行一次新的登录，并使用新的会话令牌(假设登录是单阶段的)。在手动浏览和探测应用程序时，可以通过IBurpExtender接口使用Burp代理的可扩展性特性。您可以创建一个扩展来检测应用程序何时强制注销，自动重新登录到应用程序，并将新会话和页面返回给浏览器，还可以使用弹出消息告诉您发生了什么。虽然这并不能消除问题，但在某些情况下，它可以极大地缓解问题。
Summary
会话管理机制为您在制定针对应用程序的攻击时提供了一个潜在漏洞的丰富来源。由于它的基本作用是使应用程序能够跨多个请求识别相同的用户，中断的会话管理功能通常提供王国的密钥。加入其他用户的会话是件好事。劫持管理员会话甚至更好;通常，这使您能够危害整个应用程序。
在实际的会话管理功能中，您可能会遇到各种各样的缺陷。当使用定制的机制时，可能存在的弱点和攻击途径似乎是无穷无尽的。从这个话题中得出的最重要的教训是要有耐心和决心。相当多的会话管理机制在第一次检查时看起来是健壮的，但仔细分析后会发现它们是有缺陷的。解密应用程序用来生成其看似随机的令牌序列的方法可能需要时间和独创性。但考虑到回报，这通常是一项非常值得做的投资。
Chapter 7 Attacking Session Management(3)-Weakness in Session Token Handling(2)
Chapter 8 Attacking Access Controls-Common Vulnerabilities(1)
