在实际的练习中，我们发现如果对Burpsuite中的cookie管理机制有一个大致了解的话，会更有利于实验的进行，同时在实际的渗透测试中学会使用Burpsuite进行cookie自动化处理也是一项应该具备的能力。

但是搜索了相关方面的文章，发现完整性不佳，于是笔者决定结合官方文档详细介绍下Burpsuite的会话管理机制，也作为访问控制和越权漏洞这一实验环节的序章。

功能介绍

官方文档URL：

https://portswigger.net/burp/documentation/desktop/options/sessions

简单的说Burpsuite会话管理模块包含这几个功能：

• Session handling rules：用于设置一系列会话处理规则以对请求中的cookie进行操作

• Session handling tracer：查看Burpsuite所发出请求中哪些受到了会话处理机制的更改

• Cookie jar：Burpsuite存储的访问web站点时发出的所有cookie

• Macros：用于预定义一系列请求操作

01会话处理所面临的挑战

在执行任何类型的Web应用程序测试时，您可能会遇到与会话处理和状态相关的挑战。例如：

• 应用程序可以出于防御或其他原因终止用于测试的会话，以此导致再会话恢复之前所有后续请求都是无效的；

• 有些功能模块需要随每个请求提交一个不断变更的token值(用于阻止请求伪造攻击)；

• 有些功能可能需要在进行测试请求之前发出一系列其他请求，以使应用程序进入合适的状态。

这些问题可能会在执行自动化测试任务时出现，例如进行fuzzing或扫描时，也可能在手动测试时出现。

Burpsuite的会话处理机制包含了一系列在所有这些情况下提供帮助的特性，允许您继续进行手动和自动化测试，而Burpsuite会在后台为您处理各种问题。

02Session handling rules 会话处理规则

新版位置：Project Option->Sessions->Session handling rules

旧版位置：Option->Session

Burpsuite允许您定义一组会话处理规则，让您可以非常细粒度地控制Burpsuite如何对应用程序的会话机制及相关功能进行操作。

每个规则都包含一个scope(规则适用范围)和action(规则动作)。对于Burpsuite发出的每个请求，它将确定哪些已定义的规则属于该请求的作用域，并按顺序执行这些规则的所有操作(除非条件检查操作确定不应该对该请求应用进一步操作)。

每个规则的scope可以根据所处理请求的下列特征来进行定义:

• 发出请求的Burpsuite tools；

• 请求的URL；

• 请求所包含的参数名。

每条规则可执行一个或多个action，例如：

• 从 Burpsuite 的 cookie jar中更新cookie值；

• 验证当前会话；

• 运行宏（预定义的请求序列）。

通过创建具有不同scope和acion的多个规则，您可以定义行为层次结构使得Burpsuite可以对各种不同的应用程序和功能执行不同操作。例如，在一个特定的测试中，您可以定义以下规则：

• 对于所有的请求，从Burpsuite 的 cookie jar中添加cookie；

• 对于特定域的请求，验证该应用程序的当前会话是否仍处于活动状态，如果不是，则重新运行宏登录到该应用程序，并使用生成的会话令牌更新cookie jar；

• 对于包含csrftoken参数的特定URL的请求，首先运行一个宏来获得一个有效的csrftoken值，然后附加到后续请求中。

03Session handling tracer 会话处理跟踪

将Burpsuite的会话处理功能应用到实际应用程序的特性所需要的配置通常很复杂，而且很容易出错。您可以使用会话处理跟踪程序来进行故障排除。

跟踪程序显示由会话处理功能处理的每个请求(即至少应用了一个会话规则的请求)的清单。对于每个已处理的请求，跟踪程序显示执行的规则和操作的顺序，以及在顺序中的每个步骤中对当前请求所做的更改。

注意，会话处理跟踪程序对所有受影响的HTTP请求施加处理和存储开销。因此应该只在解决会话处理规则问题时使用跟踪程序，一般不用运行。

04Cookie jar Cookie罐子

Burpsuite维护一个cookie jar，用于存储您访问Web站点时发出的所有cookie，所有Burpsuite工具共享cookie jar。

您可以配置cookie jar应该监视哪些工具以更新cookie。默认情况下，cookie jar会根据来自Proxy和Spider的流量进行更新。Burpsuite监听所配置模块中接收到的响应，并更新任何新设置的cookie。

对于Proxy模块，还会检查来自浏览器的传入请求，这对于应用程序之前设置了浏览器中存在的持久cookie，并且正确处理会话需要该cookie时会非常有用。让Burpsuite根据Proxy的请求更新它的cookie jar意味着所有必要的cookie将被添加到cookie jar中，即使应用程序在您当前的访问期间没有更新该cookie值。

点击Open cookie jar您还可以查看cookie jar的内容并进行手动编辑。

cookie jar可以被Session handling rules和Macro用于自动更新发送请求的cookie值。

cookie jar遵循cookie的域和路径范围，在某种程度上模仿Internet Explorer对cookie处理规范的解释。

05Macros 宏

宏是一个或多个请求的预定义序列，您可以在会话处理规则中使用宏来执行各种任务，宏的典型用例包括：

• 获取应用程序的页面(例如用户的主页)以检查当前会话是否仍然有效；

• 执行登录以获得一个新的有效会话令牌；

• 获取令牌或Nonce（在密码学中Nonce是一个只被使用一次的任意或非重复的随机数值）作为另一个请求的参数；

• 当在执行一个具有多步骤的fuzzing或扫描过程时，执行必要的先行请求，以使应用程序能够正确接收测试请求；

• 在一个多步骤流程中，发出“攻击”请求后，完成流程的其余步骤以确认正在执行的动作，或从该流程处获得结果或错误消息。

除了基本的请求序列外，每个宏还包括一些关于如何处理序列中的cookie和参数的重要配置，以及项之间的任何相互依赖关系。

有关的操作可以参考之前的文章>>Burpsuite练兵场-验证机制漏洞（二）

06Burpsuite内部处理cookie时的细节问题

Burpsuite的会话处理功能与Burpsuite的其他功能在一些重要方面的交互：

1、有一个默认的会话处理规则，它使用Burpsuite 的 cookie jar中的cookie更新Scanner发出的请求，除非Scanner在管理自己的会话(在爬行和爬行驱动的审计期间)。如果这不是您需要的行为，您应该在执行任何扫描之前禁用默认的会话处理规则。

2、当会话处理规则在请求发出前修改请求时(例如，为了更新cookie或其他参数)，为了清晰起见，Burpsuite的一些工具将显示最终更新的请求，这适用于Intruder、Repeater和Spider工具。在Scanner的issue报告中仍然显示原始请求，以便在必要时与基本请求进行清楚的比较。要观察由会话处理程序修改的scan issue的最终请求，您可以将请求发送到Burpsuite Repeater并在那里发送它(如果您为Repeater启用了与 Scanner相同的会话处理规则)。

3、当Scanner或Intruder发出的请求中包含有cookie或其他参数时，该请求不会受到会话管理机制的影响，以避免干扰正在执行的测试。例如，如果您正在使用Intruder对一个请求中的所有参数进行模糊测试，并且您已经配置了一个会话处理规则来更新该请求中的sessid cookie，那么使用Intruder处理其他参数时，sessid cookie将被更新，但当对Intruder中的sessid cookie参数本身进行操作时时，Burpsuite将发送Intruder中的有效负载作为sessid值，而会话处理规则不会对其产生影响。

实际应用

一个比较简单的例子就是在我们使用Burpsuite的目录扫描工具Discover content（位于右键->Engagement tools->Discover content）时，首先我们来看看Burpsuite默认的会话处理规则，一般只这样一条默认规则。

点击Edit查看具体配置，可以看到其Scope范围仅仅只有Scanner这一模块。

也就是说我们平常使用Discover content这一功能时，Burpsuite并不会自动帮助我们将已有cookie添加到请求中，以此导致使用这一目录探查功能时返回一系列4XX错误，并使得最终站点地图收录不全。

所以我们需要设置规则以开启这一cookie添加功能（当然也可以直接编辑原规则勾选Target，Discover content归属于Target scope）。

新建一条规则，选择action为use cookie jar。

切换到Scope选项卡，仅勾选Target，并选择all URLs。

点击OK就完成了规则的配置，同样在其他地方也可以根据需要进行具体配置，关键是要理解Burpsuite内部的会话管理机制。

今天的文章分享，小伙伴们看懂了吗？