参考: The Web Application Hacker’s Handbook Chapter 7
会话管理机制是大多数web应用程序中的一个基本安全组件。它使应用程序能够在多个不同的请求中惟一地识别给定的用户,并处理它积累了关于用户与应用程序交互状态的数据。在应用程序实现登录功能的地方,会话管理是特别重要的,因为它使应用程序能够在任何给定用户的身份的保证中保持它的保证,而不是他提供他的凭证的请求。
由于会话管理机制所扮演的关键角色,它们是对应用程序恶意攻击的主要目标。如果攻击者可以破坏应用程序的会话管理,她可以有效地绕过其身份验证控件,并将其伪装成其他应用程序用户,而不知道它们的凭证。如果攻击者以这种方式伤害了管理用户,攻击者就可以拥有整个应用程序。
与身份验证机制一样,通常会在会话管理功能中找到各种各样的缺陷。在最脆弱的情况下,攻击者只需增加应用程序向他发出的一个令牌的值,将其上下文转换为不同的用户。在这种情况下,应用程序对任何人都开放,可以访问所有区域。在光谱的另一端,攻击者可能必须非常努力地工作,破译几层模糊的模糊点,并设计出一个复杂的自动攻击,然后在应用程序的装甲中引入一个裂缝。
这一章介绍了作者在实际的web应用程序中遇到的所有类型的弱点。它详细说明了你需要采取的实际步骤,并利用这些缺陷。最后,它描述了应用程序应该采取的防御措施来保护自己免受这些攻击。
1.状态的必要性(Thee Need for State)
HTTP协议本质上是无状态的。它基于一个简单的请求-响应模型,其中每一对消息都代表一个独立的事务。协议本身没有任何机制来连接特定用户所提出的一系列请求,并将这些来自web服务器接收的所有请求。在Web的早期,不需要任何这样的机制:网站被用来发布静态的HTML页面,让任何人查看。今天,情况非常不同。
大多数web“站点”实际上是web应用程序。他们允许你注册和登录。他们让你买卖货物。下次你访问时,他们记得你的喜好。它们提供丰富的多媒体体验,并根据您点击和类型创建的内容。要实现此功能,web应用程序需要使用会话的概念。
会话中最明显的使用是在支持登录的应用程序中。输入您的用户名和密码后,您可以使用应用程序作为您输入的凭证,直到您注销,或者会话由于不活动而到期。如果没有会话,用户将不得不在应用程序的每一页重新输入他的密码。因此,在对用户进行身份验证后,应用程序为他创建了一个会话,并将所有来自该用户的请求都视为来自该用户。
没有登录功能的应用程序通常也需要使用会话。许多销售商品的网站不需要客户创建账户。然而,它们允许用户浏览目录,将项目添加到购物篮,提供交付细节,并支付。在这种情况下,没有必要对用户的身份进行身份验证:对于大多数访问,应用程序不知道或关心用户是谁。但是要与他做生意,它需要知道它接收的一系列请求是来自同一个用户。
执行会话中最简单、最常见的方法是为每个用户发送一个独特的会话令牌或标识器。在对应用程序的每个后续请求上,用户重新提交这个令牌,使应用程序能够确定前面请求当前请求的顺序。
在大多数情况下,应用程序使用HTTP cookie作为传递机制,以传递服务器和客户机之间的会话令牌。服务器对新客户机的第一个响应包含一个类似于下面的HTTP头:
Set-Cookie: ASP.NET_SessionId=mza2ji454s04cwbgwb2ttj55
来自客户机的后续请求包含这个标题:
Cookie: ASP.NET_SessionId=mza2ji454s04cwbgwb2ttj55
这个标准的会话管理机制本身就容易受到各种攻击类别的攻击。攻击者的主要目标是以某种方式劫持合法用户的会话,从而伪装成那个人。如果用户已向应用程序进行了身份验证,则攻击者可以访问属于用户的私有数据或对该人进行未经授权的行为。如果用户未经过身份验证,攻击者仍然可以查看用户在会话中提交的敏感信息。
与前面的例子一样,微软IIS服务器运行ASP.NET、大多数商业web服务器和web应用程序平台都基于HTTP cookie实现他们自己的现成的会话管理解决方案。它们提供了web应用程序开发人员可以使用的api,以将他们自己的会话依赖功能与此解决方案结合起来。
已经发现,一些基于会话管理的临时实现容易受到各种攻击的伤害,这导致用户的会话被破坏(这些是在本章稍后讨论的)。此外,一些开发人员发现,他们需要更多的对会话行为的微粒度控制,而不是由内置的解决方案提供给它们,或者他们想要避免基于cookie的解决方案固有的一些漏洞。出于这些原因,在诸如在线银行等安全关键应用程序中使用bespoke和/或非基于cookibased的会话管理机制是相当常见的。
在会话管理机制中存在的脆弱性主要分为两类:
- 会话令牌生成的弱点
- 在他们的生命周期中处理会话令牌的弱点 我们将依次研究这些领域,描述在现实世界的会话管理机制中常见的不同类型的缺陷,以及发现和利用这些的实用技术。最后,我们将描述应用程序可以采取的措施来保护自己免受这些攻击。
HACK STEPS
在许多使用标准cookie机制来传输会话令牌的应用程序中,很直接地确定哪些数据包含了令牌。然而,在其他情况下,这可能需要一些侦探工作。
- 1.应用程序通常可以使用几个不同的数据项作为标记,包括cookie、URL参数和隐藏的表单字段。这些项目中的一些可以用于在不同的后端组件上维护会话状态。不要假设一个特定的参数是会话令牌,而不证明它,或者通过只使用一个项来跟踪会话。
- 2.有时,似乎是应用程序会话标记的项可能不是。特别是,web服务器或应用程序平台生成的标准会话cookie可能存在,但实际上并没有被应用程序使用。
- 3.观察哪些新项目在身份验证后传递给浏览器。通常,在用户对自己进行身份验证后创建新的会话令牌。
- 4.要验证哪些项目实际上是作为令牌,找到一个绝对依赖于session的页面(例如用户特定的“我的详细”页面)。对它提出几个请求,系统地删除你怀疑被用作标记的每个项目。如果删除一个项目导致未返回的sesb依赖的页面,这可能会确认项目是一个会话标记。Burp中继器是执行这些测试的有用工具。
1.1 会话的备选方案(Alternatives to Sessions)
并不是每个web应用程序都使用会话,一些包含身份验证机制和复杂功能的安全关键应用程序选择使用其他技术来管理状态。你可能会遇到两种可能的选择:
- HTTP认证 - 使用各种基于http的身份验证技术(basic, digest, NTLM)的应用程序有时会避免使用会话。在HTTP身份验证中,客户端组件通过浏览器直接与身份验证机制交互,使用HTTP头,而不是在任何单个页面中包含的应用程序专用代码。在用户进入浏览器对话框后,浏览器可以有效地重新提交这些凭据(或重新执行任何必要的握手),并对相同的服务器进行随后的请求。这相当于一个应用程序,它使用基于HTML的基于表单的身份验证,并在每个应用程序页面上放置一个登录表单,要求用户对他们执行的每一个动作进行重新验证。因此,在使用基于http的身份验证时,应用程序可以在不使用会话的情况下,在多个请求中重新识别用户。然而,HTTP身份验证很少用于任何复杂性的基于internet的应用程序,而完全fl边缘会话机制提供的其他多功能好处意味着,实际上所有web应用程序实际上都使用了这些机制。
- 无会话状态机制 - 有些应用程序不会发布会话令牌来管理用户与应用程序的交互状态。相反,它们将所有需要的数据传输到客户端,通常是在cookie或隐藏的表单字段中。实际上,这种机制使用的是无会话状态,就像ASP.NET ViewState做。为了确保这种类型的机制,通过客户端传输的数据必须得到适当的保护。这通常需要构建一个包含所有状态信息的二进制blob,并使用识别算法对其进行加密或签名。必须包含在数据中,以防止攻击者在应用程序内的一个位置收集一个状态对象,并将其提交到另一个位置,以引起一些不良行为。应用程序还可以将对象数据的过期时间包含到执行相当于会话超时的时间。第五章详细描述了通过客户端传输数据的安全机制。
HACK STEPS
- 1.如果使用HTTP身份验证,则可能没有实现会话管理机制。使用之前描述的方法来检查任何类似于token-like的数据项所扮演的角色。
- 2.如果应用程序使用一个无状态的状态机制,传递通过客户端维护状态所需的所有数据,那么有时很难确定,但以下是这种机制正在被使用的强指标:
- 向客户机发出的token-like数据项相当长(100个或更多字节)。
- 应用程序会对每个请求发出新的token-like项。
- 该项目中的数据似乎被加密(因此没有可识别的结构)或签名(因此,有一个有意义的结构,附带了几个字节的无意义二进制数据)。
- 应用程序可能拒绝尝试以多个请求提交相同的项。
- 3.如果证据表明应用程序不使用会话令牌来管理状态,那么在本章中描述的任何攻击都不太可能实现任何东西。你的时间可能会更好地寻找其他严重的问题,比如故障的访问控制或代码注入。
Chapter 6 Attacking Authentication(4) - Securing Authentication(3)
Chapter 7 Attacking Session Management(2)-Weaknesses in Token Generation
