利用递归Grep测试每请求CSRF令牌保护的页面

本文详细介绍了如何使用Burp Intruder的递归Grep有效载荷来测试采用每请求CSRF令牌机制的Web应用程序,包括配置步骤和实际案例演示,帮助安全测试人员解决自动化测试中的令牌依赖问题。

利用递归Grep测试每请求CSRF令牌保护的页面

跨站请求伪造(CSRF或XSRF)是一种攻击方式,攻击者利用受害用户身份在易受攻击的Web应用程序上执行交易。要使CSRF攻击成功,攻击者必须能够预先确定并提交执行目标交易所需的所有值。如果可能,攻击者会使用社会工程学手段,制作恶意URL或在接受未过滤HTML输入的第三方网站上发布恶意表单。当目标用户执行攻击者的内容时,交易将在目标Web应用程序上执行。

作为防御CSRF攻击的一种措施,Web应用程序在敏感表单中使用反CSRF令牌。该令牌是在目标表单加载时生成的随机值,并在表单提交时进行验证。由于攻击者无法提前知道该值,并且必须拥有该值才能成功提交表单,因此当正确实施时,这种技术将阻止CSRF攻击。

一些反CSRF实现在每次提交表单时更改令牌值。这种行为的一个副作用是,如果不考虑令牌值,自动化测试几乎变得不可能。在本文中,我将演示如何使用Burp Intruder的递归Grep有效载荷来解决这个问题。一旦理解了递归Grep有效载荷,它几乎可以用于解决对先前服务器响应的任何依赖。

我最近遇到了一个WebSphere门户,它表现出上述行为。当任何表单提交到服务器时,后续响应中的多个值会发生变化,这阻止了像Burp Repeater和Burp Intruder这样的自动化工具在网站上正常工作。服务器只会通过重新加载带有新更新令牌值的空白表单来响应。

为了演示这个问题,我创建了一个带有两个字段的ASP.NET Web表单。为简单起见,当前令牌值显示在表单上。如果提交此表单时没有正确的令牌值,将显示字符串“无效令牌值”。但是,当提交正确的令牌值时,提交的值会反映在页面上,并显示成功指示。

带有显示令牌值的基本表单

令牌验证错误

成功的表单提交

如果不补偿令牌值,当运行Burp Intruder尝试篡改表单字段时,我们会看到以下结果。这是因为令牌随着每个请求而变化,并在表单提交时进行验证。由于值不匹配,所有请求都不成功。

为了适应响应中存在的令牌值,我们可以使用Burp Intruder递归Grep有效载荷。该有效载荷将根据先前的服务器响应制定参数并将其插入到您的请求中。派生参数可以来自响应中的任意位置,并且您可以根据需要包含任意多个递归grep有效载荷。在测试上述WebSphere门户时,有三个不同的值随着服务器的每个响应而变化。

为了使用递归Grep有效载荷,我们必须对标准Intruder攻击设置进行一些调整。在上面的实例中,我简单地选择了txtFName参数,指定了使用简单列表有效载荷的狙击攻击,并选择了默认的Burp用户名列表。

使用递归Grep要求我们选择Pitchfork或Cluster Bomb攻击类型。由于我们只篡改一个参数,Pitchfork攻击是有意义的。这种攻击将在最短列表耗尽时停止。对于多个重要参数,这种攻击将每个列表中的值视为元组。相比之下,Cluster Bomb攻击测试每个列表生成的所有可能排列。我们的设置如下所示。目标字段(txtFName)和令牌(checkToken)被标识为有效载荷位置,攻击类型为Pitchfork。

由于目标字段首先出现在请求中,我们选择简单列表作为有效载荷类型,并如前所述指定Burp用户名列表。

第二个字段是我们的checkToken值。在这种情况下,我们需要一个递归Grep有效载荷,但首先我们必须设置Grep位置。为此,我们必须导航到选项选项卡并向下滚动到表单中的“Grep Extract”位置。

到达那里后,单击添加按钮以添加提取位置。在随后的表单中,向下滚动HTTP响应正文并突出显示CSRF令牌值。这标识了Burp将用于Burp递归Grep有效载荷的先前响应中的位置。

在选项选项卡上需要进行最后一项调整,以确保递归grep正常工作。由于先前响应和当前请求之间存在直接关系,线程数必须设置为1。

在代理上启用拦截后,提交表单以捕获当前令牌值。这是播种递归Grep有效载荷所必需的,并将用于开始intruder攻击。

现在,返回到Burp Intruder攻击并选择Payloads选项卡。选择适当的有效载荷索引并选择递归Grep有效载荷类型。您应该看到上面创建的Grep Extract条目。选择此值并将当前令牌值粘贴到“初始有效载荷用于第一个请求”字段中。

设置完所有选项后,我们最终可以执行我们的Intruder攻击。由于“checkToken”参数被选为篡改值,我们可以在攻击中看到提交的值。此外,由于需要Grep Extract来促进攻击,我们可以看到先前表单提交中返回的值。检查输出,我们可以看到响应指示成功,单词“invalid”不再出现在输出中,并且令牌值按预期从响应级联到请求。

希望这篇文章在您遇到类似行为时会有价值。虽然递归Grep有效载荷对某些反CSRF行为有效,但它不是一刀切的解决方案。

在迫使我研究递归Grep有效载荷的同一个WebSphere门户中,有一些多步表单提交是这个功能无法处理的。这些表单涉及对同一位置的多个帖子。每个帖子生成新的令牌值,这些值必须按顺序提交。一组令牌将激活表单,下一组将提交。没有第一组,页面将简单地重新加载而没有活动表单。

我目前正在研究这个问题的解决方案,并已启动一个Burp扩展来解决它。在未来的文章中寻找这个功能……

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计