在实际的练习中,我们发现如果对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
每个规则都包含一个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 会话处理跟踪
跟踪程序显示由会话处理功能处理的每个请求(即至少应用了一个会话规则的请求)的清单。对于每个已处理的请求,跟踪程序显示执行的规则和操作的顺序,以及在顺序中的每个步骤中对当前请求所做的更改。
注意,会话处理跟踪程序对所有受影响的HTTP请求施加处理和存储开销。因此应该只在解决会话处理规则问题时使用跟踪程序,一般不用运行。
04Cookie jar Cookie罐子
您可以配置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默认的会话处理规则,一般只这样一条默认规则。
也就是说我们平常使用Discover content这一功能时,Burpsuite并不会自动帮助我们将已有cookie添加到请求中,以此导致使用这一目录探查功能时返回一系列4XX错误,并使得最终站点地图收录不全。
所以我们需要设置规则以开启这一cookie添加功能(当然也可以直接编辑原规则勾选Target,Discover content归属于Target scope)。
新建一条规则,选择action为use cookie jar。
今天的文章分享,小伙伴们看懂了吗?