4.6.3-测试 Session Fixation

测试 Session Fixation

ID
WSTG-SESS-03

总结

会话固定是通过在身份验证之前和之后保留会话 cookie 的相同值的不安全做法实现的。当会话 cookie 用于存储状态信息时，通常会发生这种情况，甚至在登录之前，例如，在验证付款之前将商品添加到购物车。

在会话固定漏洞的一般利用中，攻击者可以从目标站点获取一组会话 cookie，而无需首先进行身份验证。然后，攻击者可以使用不同的技术将这些 cookie 强制进入受害者的浏览器。如果受害者后来在目标站点进行身份验证，并且 cookie 在登录时没有刷新，则攻击者选择的会话 cookie 将识别受害者。然后，攻击者能够使用这些已知 cookie 冒充受害者。

可以通过在身份验证过程后刷新会话 Cookie 来解决此问题。或者，可以通过确保会话 Cookie 的完整性来防止攻击。在考虑网络攻击者时，即控制受害者使用的网络的攻击者，使用完整的 HSTS 或在 cookie 名称中添加__Host- / __Secure- 前缀。

当主机为自己及其所有子域激活 HSTS 时，将发生完全 HSTS 采用。Stefano Calzavara、Alvise Rabitti、Alessio Ragazzo 和 Michele Bugliesi 在一篇名为“Testing for Integrity Flaws in Web Sessions”的论文中对此进行了描述。

测试目标

• 分析身份验证机制及其流程。
• 强制使用 Cookie 并评估影响。

如何测试

在本节中，我们将对测试策略进行解释，该策略将在下一节中展示。

第一步是向要测试的网站发出请求（例如www.example.com）。如果测试人员请求以下内容：

GET / HTTP/1.1
Host: www.example.com

他们将获得以下响应：

HTTP/1.1 200 OK
Date: Wed, 14 Aug 2008 08:45:11 GMT
Server: IBM_HTTP_Server
Set-Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1; Path=/; secure
Cache-Control: no-cache="set-cookie,set-cookie2"
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html;charset=Cp1254
Content-Language: en-US

应用程序为客户端设置一个新的会话标识符， JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1。
接下来，如果测试人员通过以下POST成功地对应用程序进行了身份验证，该POST地址为https://www.example.com/authentication.php

POST /authentication.php HTTP/1.1
Host: www.example.com
[...]
Referer: http://www.example.com
Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1
Content-Type: application/x-www-form-urlencoded
Content-length: 57

Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in

测试人员观察到来自服务器的以下响应：

HTTP/1.1 200 OK
Date: Thu, 14 Aug 2008 14:52:58 GMT
Server: Apache/2.2.2 (Fedora)
X-Powered-By: PHP/5.1.6
Content-language: en
Cache-Control: private, must-revalidate, max-age=0
X-Content-Encoding: gzip
Content-length: 4090
Connection: close
Content-Type: text/html; charset=UTF-8
...
HTML data
...

由于在成功进行身份验证后没有发出新的 cookie，因此测试人员知道，除非确保会话 cookie 的完整性，否则可以执行会话劫持。

测试人员可以向用户发送有效的会话标识符（可能使用社会工程技巧），等待他们进行身份验证，然后验证是否已为此 Cookie 分配权限。

使用强制 Cookie 进行测试

此测试策略针对网络攻击者，因此只需应用于未完全采用 HSTS 的站点（完全采用 HSTS 的站点是安全的，因为其所有 Cookie 都具有完整性）。我们假设在被测网站上有两个测试账户，一个充当受害者，另一个充当攻击者。我们模拟了这样一种情况：攻击者在受害者的浏览器中强制使用登录后不是新发出且不具有完整性的所有 cookie。受害者登录后，攻击者将强制 cookie 提供给网站以访问受害者的帐户：如果它们足以代表受害者采取行动，则可以进行会话固定。

以下是执行此测试的步骤：

1. 到达站点的登录页面。
2. 在登录之前保存 cookie jar 的快照，不包括名称中包含 __Host- or __Secure- 前缀的 cookie。
3. 以受害者身份登录该站点，并访问任何提供需要身份验证的安全功能的页面。
4. 将 Cookie jar 设置为在步骤 2 中拍摄的快照。
5. 触发步骤 3 中标识的安全函数。
6. 观察步骤 5 的操作是否执行成功。如果是这样，则攻击成功。
7. 清除 cookie jar，以攻击者身份登录，并在第 3 步中访问该页面。
8. 在 cookie jar 中逐个写入步骤 2 中保存的 cookie。
9. 再次触发步骤 3 中标识的安全函数。
10. 清除 cookie jar 并以受害者身份再次登录。
11. 观察受害者账户中是否成功执行了步骤 9 的操作。如果是这样，则攻击成功;否则，该站点是安全的，不会受到会话固定。

我们建议对受害者和攻击者使用两台不同的机器或浏览器。这允许您在 Web 应用程序执行指纹识别以验证从给定 Cookie 启用的访问时减少误报的数量。较短但不太精确的 testing 策略变体只需要一个 testing account。它遵循相同的步骤，但在步骤 6 处停止。

修复

在用户成功进行身份验证后实施会话令牌续订。

在对用户进行身份验证之前，应用程序应始终首先使现有会话 ID 失效，如果身份验证成功，则提供另一个会话 ID。

工具

• ZAP

引用

• Session Fixation
• ACROS Security
• Chris Shiflett