会话固化漏洞_查找特定于会话管理的漏洞

会话固化漏洞

会话管理特有的漏洞是对任何Web应用程序的巨大威胁，也是查找和修复最具挑战性的漏洞之一。 会话是恶意用户的目标，因为它们可以用于无需身份验证即可获得对系统的访问权限。

本教程描述了会话管理概念以及如何使用IBM SecurityAppScan®Standard有效地查找特定于会话管理的漏洞。

本教程还清楚地描述了验证IBM Security AppScan Standard中检测到的与会话相关的漏洞的方法，从而消除了调查结果中的误报。 我们还使用交互式方法描述了与会话相关的一些概念以及与会话相关的潜在风险。

会话管理概念

会话管理方案

首先，什么是网络会话？ 为了使您形象化，请考虑在网上购物的常见情况。

• 作为注册客户，您只需使用有效的登录凭据登录到购物门户即可成功购买商品。
• 除非登录的会话超时或在执行所有这些活动时执行特权操作（例如管理员访问），否则应用程序不会期望用户一次又一次地提供凭据。 用户无法在应用程序内部的每次单击中提供凭据来验证其操作。

那么，应用程序如何识别合法用户在该第一次会话之后发出了预期的请求？ 会话管理允许应用程序让用户参与一次身份验证，并确认用户正在执行特定操作的用户是提供原始凭据的用户。

追踪使用者

通过网站跟踪客户的最常见方法是分配唯一的会话ID，并将此信息随每个请求传递回Web服务器。 客户端在Web应用程序上成功进行身份验证后，可以将生成的会话ID用作存储的身份验证令牌，以便客​​户端无需在每个页面请求中都重新输入其登录信息。

尽管有几种分配和接收会话ID信息的方法，但最常用的方法是cookie。 会话信息存储在服务器上，并使客户端存储其信息的会话标识符。 会话ID使用cookie（用户浏览时从网站发送并由用户的Web浏览器存储在用户计算机上的一小段数据）存储，然后服务器使用会话ID检索信息。它存储的。

由于会话ID用于唯一标识和跟踪Web应用程序用户，因此攻击者可能能够提交此相同信息并冒充其他人。 此类攻击通常称为会话劫持。 由于HTTP（或HTTP）协议的无状态性质，攻击者可以使用被劫持的会话ID轻松地将自己描绘成合法用户。

常见的失败

尽管基于Web的会话管理对于跟踪用户及其在整个应用程序中的导航很重要，但它最重要的用途是在用户执行允许的功能时维护经过身份验证的用户的状态信息。 状态信息的一些示例包括当前用户的身份，购物车的内容以及数据库连接字符串。 对于在线银行和零售环境，使用适当强大的会话管理方法对于组织的成功至关重要。

根据调查，一些最常见的失败是：

• 可预测的会话ID
• 不安全的传输（例如不使用HTTPS）
• 会话有效期
• 会话验证

根据IBM Security AppScan Standard的常见发现，确定了与这四个列出的故障相关的一些漏洞。 在本教程中，我们将仔细研究这些漏洞，并提供有关如何验证这些漏洞的步骤。

配置IBM Security AppScan Standard进行会话管理

有关应用程序安全性的更多信息，请立即访问IBM Security AppScan Standard 。

在本节中，我们描述如何配置IBM Security AppScan Standard以有效地发现特定于会话管理的漏洞。

IBM Security AppScan Standard具有有效的会话管理功能。 一种这样的关键功能是“登录管理”配置中可用的“记录的登录”选项。

AppScan Standard提供了一个选项来记录目标Web应用程序的登录顺序，可以通过以下步骤完成：

1. 导航对扫描配置>登录管理 。 打开“ 登录/注销”选项卡，然后选择“已录制” 。
2. 您可以使用AppScan浏览器记录登录顺序。 （如果适当的代理设置到位，也可以使用其他浏览器来记录登录顺序。）

   图1：“扫描配置”窗口

   
3. AppScan浏览器将打开目标应用程序的登录页面，您将在其中使用您的凭据登录。

   图1.1：应用程序的登录页面

   
4. 登录到应用程序后，单击“我已登录到站点”。

   图1.2：显示必要功能的登录页面

   

该工具现在将尝试分析登录数据并建立登录序列，以识别会话中页面上出现的“会话中检测模式”。 在扫描期间，AppScan重复发送会话中请求，并检查响应是否包含会话中检测模式。

如果AppScan在页面的响应中未找到该模式，则认为该模式已注销，并通过重播登录序列以尝试在扫描过程中检查工具是否处于会话中来尝试再次登录。 此方法提高了会话管理效率。 我建议您记录一个登录序列，以改善会话的扫描输出。

要进一步了解此顺序，请参阅文档IBM Security AppScan Enterprise Edition –扫描配置最佳实践。

以下各节介绍了可用于验证与会话相关的漏洞的所有方法。

• 会话标识符未更新
• 注销后会话未失效
• 帐户锁定不足
• 加密会话（SSL）Cookie中缺少安全属性
• 会话cookie中的仅HTTP属性缺失

会话标识符未更新：中等严重性

将会话ID分配给用户后，在活动会话结束后，使SessionID无效或更新是正常的。 如果在对用户进行身份验证或建立新的用户会话时未能使现有会话标识符无效，则攻击者将有机会窃取经过身份验证的会话。 这些被劫持的会话ID可用于模拟合法用户。 攻击者还能够在用户身上强加一个已知的会话标识符，以便一旦用户进行身份验证，攻击者就可以访问经过身份验证的会话。

验证步骤

1. AppScan运行扫描时，会自动查找漏洞。 在“问题列表”中查找检测到的漏洞。 记下问题，然后检查“ 请求/响应”选项卡。

   图2：AppScan问题列表显示“会话标识符未更新”

   
   
2. 从“请求/响应”选项卡中，我们得出以下结论：
   • 在客户端从浏览器启动的登录（POST）请求期间，服务器将设置会话cookie ASP.NET_SessionId。 该值为ASP.NET_SessionId= pz4p3qu5mfbzij3z0uavta55如以下屏幕截图所示。

     图2.1：启动请求时的请求/响应

     
   • 从图2.1的上面的屏幕截图可以看出，该请求已被重定向。
   • 最后，当用户登录其帐户时，我们假设会话cookie值已更改。 但是，如果我们在登录后注意到ASP.NET_SessionId的值，则该值将保持不变。 这是会话管理不善的一个例子。

     图2.2：请求/响应后重定向

     
3. 我们可以验证会话管理的另一种方法是通过浏览器插件Advanced Cookie Manager，您可以将其安装在浏览器中。 在本教程中，我们使用Firefox和Advanced Cookie Manager，但其他浏览器也可以使用类似的附件。

   图2.3：Advanced Cookie Manager浏览器附加组件

   
4. 打开测试/目标应用程序。
5. 从工具栏打开高级Cookie管理器。
6. 我们可以在域列表中找到所需的应用程序域，在下图中圈出数字1。

   图2.4：高级Cookie Manager界面预登录

   
7. 与该域相关联的cookie位于“ Cookie”部分中，该部分带有圈号2。
8. 现在，我们选择一个会话cookie，以检查会话是否已更新。 选择ASP.NET_SessionId （这是一个会话cookie，因为isSession标志为On（圆圈编号3）。请记下Value（圆圈编号4）。
9. 此会话cookie的值很可能在登录后更改。 要确认，请按照下列步骤操作：
   • 确保您已登录到目标应用程序。
   • 登录后，单击Advanced Cookie Manager中的刷新按钮（请参见下面的图2.5中的绿色方块）。

     图2.5：高级Cookie Manager登录后

     
   • 请注意， ASP.NET_SessionId的值在登录后保持不变。 而且，即使我们注销，此会话cookie的值仍保持不变。 （注销后，可以使用相同的过程进行检查）。
   • 因此，我们可以得出结论，会话ID的值没有更新。 不幸的是，如果攻击者窃取了该会话ID信息，那么这很容易劫持和操纵另一个用户的活动会话。

注销后会话无效：高严重性

在用户注销后会话ID不会失效的应用程序中存在此漏洞。 如前所述，会话ID将在注销后失效/过期，或者在注销后更新（会话ID的值在注销后更改）。

在某些情况下，会话ID保持不变或注销后仍然有效，攻击者可以使用该会话ID轻松访问帐户。

验证步骤

1. 在AppScan的“问题列表”中标记问题，然后检查“请求/响应”。

   图3：带有漏洞“注销后会话未失效”的AppScan问题列表

   
2. 要验证此漏洞：
   1. 确保用户已退出应用程序。
   2. 单击浏览器中的“ 后退”按钮。 如果该应用程序未提示您再次登录并登陆该应用程序，则表示该会话未过期，并且用户仍可以使用上一个会话登录。
3. 您可以通过检查会话cookie以及它们是否已过期或更新来进一步验证同一问题，以确保不能再次使用上一个会话。

在某些情况下，如果显示页面的缓存版本，则单击“上一步”按钮意味着您可能需要从服务器刷新页面。 如果注销功能导致将会话cookie设置为新值，则需要还原会话cookie的旧值，并且将从应用程序的已验证区域重新加载页面。 如果这些测试未在页面上显示任何漏洞，则至少应将应用程序的其他一些页面视为安全性至关重要的页面，将进行测试以确保应用程序的这些区域正确识别会话终止。

如果服务器未能使会话标识符无效，则有可能会窃取或操纵客户会话和cookie，这可能会冒充合法用户。 该漏洞使黑客可以查看或更改用户记录并以原始用户身份执行交易。

帐户锁定不足：严重程度为中等

在帐户锁定不足的情况下，请考虑以下常见情况：黑客希望登录社交网站中另一个用户的帐户，该帐户已经知道目标用户的用户名。 他不知道密码，但是根据应用程序中使用的密码策略，他可以尝试猜测密码。

此漏洞可能导致通常被称为蛮力攻击的攻击所利用。 蛮力攻击是通过系统地尝试字母，数字和符号的每种可能的组合来发现密码的尝试，直到攻击者发现有效的一种正确组合为止。

黑客使用广泛可用的工具发起暴力攻击，例如Burp Suite（Intruder），该工具利用单词列表和智能规则集来智能地自动猜测密码。 尽管此类攻击很容易检测，但并不是很容易预防。 例如，许多HTTP蛮力工具可以通过打开的代理服务器列表传输请求。 由于每个请求似乎都来自不同的IP地址，因此仅通过阻止IP地址就无法阻止这些攻击。 更复杂的是，某些工具在每次尝试中尝试使用不同的用户名和密码，因此甚至无法为失败的密码锁定单个帐户。 尽管有几种措施可以避免以后再发生类似的攻击。

安全最佳实践建议，经过3-5次无效尝试后，帐户将被锁定，应用程序将显示正确的错误消息（“帐户已被锁定”），以防止暴力攻击。 未能正确采用此策略的应用程序可能成为这种暴力攻击的牺牲品。

验证步骤

1. 在AppScan的“问题列表”中标记问题，然后检查“请求/响应”。

   图4：带有漏洞“帐户锁定不足”的AppScan问题列表

   
2. 检查“请求/响应”选项卡右侧的“推理”列。

   图4.1：“请求/响应”选项卡中的推理

   
   • 上图中提供的推理表明，最初使用一组有效凭据登录到该帐户的工具。 除此之外，该工具尝试使用无效密码多次登录（尝试3-5次以上）。 最后，该工具尝试使用有效密码再次登录。 但是没有消息表明该帐户已被锁定，这表明在这种情况下可能会成功进行暴力破解。
   • 完整阅读请求/响应，以检查成功和失败尝试之间的差异以及每种情况下响应的模式。

也可以手动检查相同的过程。 您可以尝试多次提供无效的密码，以检出帐户锁定机制，前提是该机制不需要大量的工作来解锁帐户，从而允许用户尝试再次进行身份验证。

加密会话（SSL）Cookie中缺少安全属性：严重性中等

尽管验证该问题的工作量很小，但在最小化攻击方面非常有效。 如果攻击者能够获取身份验证cookie，则他可以很容易地冒充合法用户。

假设使用HTTP作为通信协议，并且cookie以纯文本形式发送，这对于窃听浏览器与服务器之间的通信通道的攻击者来说是理想的选择。 攻击者可以获取Cookie并冒充用户。 现在，假设使用HTTPS代替HTTP。 HTTPS提供加密，攻击者将看不到cookie。 结论是通过安全通道发送身份验证cookie，以使黑客无法进行窃听。

一个常见的问题是，如果我们使用已经提供了加密通道的HTTPS，为什么我们需要一个安全标志？ 本节涵盖了有关在加密的会话cookie中添加安全属性的问题。

在这种情况下，这种情况很典型：通过HTTP和HTTPS都可以使用站点。 攻击者位于浏览器和服务器之间的通信通道的中间。 通过HTTPS发送的cookie不能被窃听。 但是，攻击者可以利用该站点也可以通过HTTP进行访问这一事实。 攻击者可以将网站的HTTP版本的链接发送给用户。 用户单击链接，然后生成HTTP请求。 由于HTTP通信是以纯文本形式发送的，因此攻击者窃听了通信通道并读取了用户的身份验证cookie。

那么，如何避免此漏洞？ 我们可以允许仅通过HTTPS发送此Cookie吗？ 事实证明这是可能的，并且为此目的使用了安全标志。 具有安全标志的cookie将仅通过HTTPS连接发送。

验证步骤：

1. 在AppScan的“问题列表”中标记问题，然后检查“请求/响应”。

   图5：带有漏洞“加密的会话Cookie中缺少安全属性”的AppScan问题列表

   
2. 使用高级Cookie管理器来验证漏洞。
   • 打开目标应用程序（在本例中为http://demo.testfire.net/）
   • 从工具栏打开高级Cookie管理器

     图5.1：高级Cookie管理器，显示Cookie的安全标志

     
3. 在这里，我们考虑如图5.1所示的cookie ASP.NET_SessionId 。 标志/属性isSecure显示为False 。 安全标记与此Cookie无关，这可能会导致攻击者通过网络窃听进一步利用。

会话cookie中缺少HttpOnly属性：低严重性

仅HTTP的cookie背后的概念是训练浏览器，以便永远不会通过JavaScript通过document.cookie属性访问cookie。 要创建仅HTTP的cookie，请将HttpOnly标志添加到cookie。 设置此标志后，将无法通过“ document.cookie”访问此Cookie。

要检查是否已将HttpOnly标志添加到会话cookie，我们可以从AppScan的“请求/响应”选项卡中检查“响应头”。 下图是添加的cookie属性的示例。

图6：显示cookie属性的请求/响应

进一步的验证步骤

1. 在AppScan的“问题列表”中标记问题，然后检查“请求/响应”。

   图6.1：带有漏洞“会话Cookie中缺少HttpOnly属性”的AppScan问题列表

   
2. 您也可以使用在线工具http://web-sniffer.net来验证会话。

   图6.2：Web-Sniffer应用程序界面

   
3. 单击提交以输入HTTP（S）URL。

   图6.3：显示cookie属性的Web嗅探器界面

   
4. 从Web-Sniffer的响应标头中，我们可以看到HttpOnly标志没有添加到会话cookie amSessionId中，如图6.1所示。 而它被添加到另一个会话cookie ASP.NET_SessionId ，因此AppScan不会报告。
5. 您也可以使用高级Cookie管理器进行验证。

   图6.4：高级Cookie管理器显示HttpOnly属性

   
6. 此外，您还可以使用Firebug（Firefox扩展程序）进行验证。
   1. 使用Mozilla Firefox打开Firebug扩展。
   2. 导航到Cookies标签。
   3. 检查HttpOnly标志是否已添加到需要验证的cookie中。
   4. 图6.5显示HttpOnly属性未添加到AppScan报告的会话cookie amSessionId中。 因此，HttpOnly字段为空。 但是，它被添加到另一个会话cookie ASP.NET_SessionId并且该字段显示HttpOnly。

      图6.5：Firebug显示空的HttpOnly字段

      

查询中URL /密码参数中的会话ID：高严重性

学到更多。 开发更多。 连接更多。

新的developerWorks Premium会员计划提供了对强大的开发工具和资源的无障碍使用的通行证，其中包括通过Safari图书在线为应用程序开发人员提供的500种顶级技术标题，主要开发人员活动（包括IBM InterConnect ，最近O'Reilly的视频回放）的大幅折扣。会议，以及更多内容。 了解developerWorks Premium的价值 。

除了前面几节中列出的常见漏洞之外，还有其他一些问题需要注意适当的会话管理。 本节中关于查询中的密码参数（或URL中的会话ID）描述了另一个主要漏洞。

如果在URL中发送了会话ID，则攻击者很容易获得该会话。

图7显示了一个应用程序，其中会话ID通过URL以明文形式发送。 任何在网络上窃听的黑客或当前用户系统后面的任何其他人都可以轻松使用此ID并模拟当前用户。 我们建议将这些ID或敏感信息通过请求的正文部分和加密连接（例如SSL）发送到服务器。

图7：URL中的会话ID

想更多地了解误报？

有关误报的更多信息，请阅读识别并避免使用IBM AppScan的误报 。

结论

会话管理漏洞的识别要求对会话管理概念有透彻的了解。 通过将IBM Security AppScan Standard与适当的配置一起使用，我们可以检测到本文涵盖的漏洞。 但是，安全分析人员还需要手动验证它们，以确保它们不是误报。

掌握了如何通过会话ID解决漏洞的知识，从会话管理的角度来看，您可以确保应用程序具有良好的安全状态。

下载Security AppScan Standard的免费试用版

---

翻译自: https://www.ibm.com/developerworks/security/library/se-session-vulnerabilities-trs/index.html

会话固化漏洞