条件竞争初探

合集 - burpsuite靶场学习(12)

1.API初探2024-12-112.XSS初探及实验2024-11-073.业务漏洞初探2024-11-064.命令注入初探2024-11-29

5.条件竞争初探2024-11-06

6.SSRF初探2024-11-067.服务器端漏洞基础2024-11-068.访问控制与权限提升初探2024-11-069.XXE初探2024-11-0610.nosql注入初探2024-11-0611.SQL注入备忘录2024-11-0612.SQL注入初探2024-11-06

收起

比赛条件

争用条件是一种常见的漏洞类型，与业务逻辑缺陷密切相关。当网站在没有足够保护措施的情况下同时处理请求时，就会发生这种情况。这可能导致多个不同的线程同时与相同的数据进行交互，从而导致“冲突”，从而导致应用程序中出现意外行为。争用条件攻击使用精心定时的请求来造成故意冲突，并利用这种意外行为来达到恶意目的。

可能发生碰撞的时间段称为“比赛窗口”。例如，这可能是与数据库的两次交互之间的几分之一秒。

与其他逻辑缺陷一样，争用条件的影响很大程度上取决于应用程序及其发生的特定功能。

在本节中，您将学习如何识别和利用不同类型的争用条件。我们将教您 Burp Suite 的内置工具如何帮助您克服执行经典攻击的挑战，以及一种久经考验的方法，使您能够在隐藏的多步骤进程中检测新类别的争用条件。这些远远超出了您可能已经熟悉的限制超限。

PortSwigger研究

像往常一样，我们还提供了一些故意容易受到攻击的实验室，您可以使用它们来针对现实目标安全地练习所学知识。其中许多是基于 PortSwigger 的原始研究，该研究首次在 Black Hat USA 2023 上展示。

有关更多详细信息，请查看随附的白皮书：粉碎状态机：Web 竞争条件的真正潜力

1、限制超限竞争条件

最广为人知的争用条件类型使您能够超过应用程序的业务逻辑施加的某种限制。

例如，考虑一家在线商店，该商店允许您在结账时输入促销代码以获得订单的一次性折扣。若要应用此折扣，应用程序可以执行以下高级步骤：

1. 检查是否尚未使用此代码。
2. 将折扣应用于订单总额。
3. 更新数据库中的记录，以反映您现在已使用此代码的事实。

如果以后尝试重用此代码，则在过程开始时执行的初始检查应阻止您执行此操作：

现在考虑一下，如果以前从未应用过此折扣代码的用户尝试在几乎完全相同的时间应用两次，会发生什么：

如您所见，应用程序通过临时子状态转换;也就是说，在请求处理完成之前，它进入然后再次退出的状态。在这种情况下，子状态从服务器开始处理第一个请求时开始，到更新数据库以指示您已使用此代码时结束。这引入了一个小的比赛窗口，在此期间您可以根据需要多次重复申请折扣。

这种攻击有很多变体，包括：

• 多次兑换礼品卡
• 多次对产品进行评分
• 提取或转账超过账户余额的现金
• 重用单个 CAPTCHA 解决方案
• 绕过反暴力破解速率限制

限制超支是所谓的“检查时间到使用时间”（TOCTOU） 缺陷的子类型。在本主题的后面部分，我们将介绍一些不属于这些类别的竞争条件漏洞示例。

使用 Burp Repeater 检测和利用极限超限竞争条件

检测和利用极限超限竞争条件的过程相对简单。概括地说，您需要做的就是：

1. 确定具有某种安全影响或其他有用用途的一次性或速率限制终结点。
2. 快速连续地向此终端节点发出多个请求，以查看是否可以超过此限制。

主要的挑战是确定请求的时机，以便至少两个比赛窗口排成一行，从而导致碰撞。这个窗口通常只有几毫秒，甚至可能更短。

即使您完全在同一时间发送所有请求，在实践中也存在各种不可控和不可预测的外部因素，这些因素会影响服务器处理每个请求的时间和顺序。

Burp Suite 2023.9 为 Burp Repeater 添加了强大的新功能，使您能够轻松发送一组并行请求，从而大大减少这些因素之一（即网络抖动）的影响。Burp 会自动调整它使用的技术以适应服务器支持的 HTTP 版本：

• 对于 HTTP/1，它使用经典的最后一字节同步技术。
• 对于 HTTP/2，它使用单数据包攻击技术，该技术由 PortSwigger Research 在 2023 年美国黑帽大会上首次展示。

单包攻击通过单个TCP报文同时完成20-30个请求，完全消除网络抖动的干扰。

尽管您通常只能使用两个请求来触发漏洞利用，但发送大量此类请求有助于缓解内部延迟（也称为服务器端抖动）。这在初始发现阶段特别有用。我们将更详细地介绍这种方法。

阅读更多

• 关于如何利用打嗝中继器新功能并行发送多个请求，请参见并行发送请求。
• 有关单数据包攻击的基本机制的技术见解，以及更详细的方法，请查看随附的白皮书：粉碎状态机：Web 竞争条件的真正潜力

实验1 限制超限竞争条件

此实验室的采购流程包含争用条件，使你能够以意外价格购买物料。

官方答案讲解

一、预测潜在碰撞

1. 登录并购买最便宜的商品，确保使用提供的折扣代码，以便您可以研究购买流程。

2. 考虑到购物车机制，特别是决定您可以订购什么的限制，值得尝试绕过。

3. 在 Burp 中，从代理历史记录中，标识使您能够与购物车交互的所有端点。例如，请求将商品添加到购物车，并且请求应用折扣代码。POST /cart POST /cart/coupon

4. 尝试确定这些终结点上存在的任何限制。例如，请注意，如果您多次尝试应用折扣代码，您会收到响应。Coupon already applied

5. 确保您的购物车中有一件商品，然后将请求发送到 Burp Repeater。GET /cart

6. 在 Repeater 中，尝试发送带有和不带有会话 cookie 的请求。确认如果没有会话 cookie，您只能访问空购物车。由此可以推断：GET /cart

   • 购物车的状态存储在会话中的服务器端。
   • 购物车上的任何操作都以会话 ID 或关联的用户 ID 为键。

   这表明存在碰撞的可能性。

7. 请注意，在您首次应用折扣代码和数据库更新以反映您已经执行此操作之间可能存在竞争窗口。

二、对行为进行基准测试

1. 确保您的购物车当前没有应用折扣代码。
2. 将应用折扣代码 （） 的请求发送到 Repeater。POST /cart/coupon
3. 在 Repeater 中，将新选项卡添加到组中。有关如何执行此操作的详细信息，请参阅创建新选项卡组。
4. 右键单击分组选项卡，然后选择“复制选项卡”。创建 19 个重复的选项卡。新选项卡将自动添加到组中。
5. 按顺序发送请求组，使用单独的连接以减少干扰的机会。具体操作方法，请参见按顺序发送请求。
6. 请注意，第一个响应确认已成功应用折扣，但其余响应始终拒绝具有相同优惠券已应用消息的代码。

三、探查线索

1. 从购物车中删除折扣代码。
2. 在 Repeater 中，再次发送请求组，但这次是并行发送，有效地同时多次应用折扣代码。有关如何执行此操作的详细信息，请参阅并行发送请求。
3. 研究响应，并观察多个请求收到的响应，指示代码已成功应用。如果没有，请从购物车中删除代码并重复攻击。
4. 在浏览器中，刷新您的购物车并确认 20% 的折扣已多次应用，从而使订单便宜得多。

四、证明概念

1. 从购物车中删除应用的代码和任意商品，然后将皮夹克添加到购物车中。
2. 并行重新发送请求组。POST /cart/coupon
3. 刷新购物车并检查订单总额：
   • 如果订单总额仍高于剩余的商店积分，请删除折扣代码并重复攻击。
   • 如果订单总额少于您剩余的商店积分，请购买夹克以解决实验室问题。

实操过程：

首先把每个过程的数据包都抓取到，然后开始分析

首先进行测试，尝试修改添加到购物车时的数量，有无漏洞，发现不行，之前还有的整数最大值突破，也不行，之前的还有的流程中出现的问题，也是不行。至于优惠券方面，因为只给了一个优惠券，所以之前的优惠券交替使用来绕过检测也是不行的。

那么进行符号主题的测试，竞争条件，在这么多的流程中，可能还有的是优惠券，因为我们像低价买入的话，这样最好，在支付的使用竞争，或许会多付款，而添加商品就更不要说了。所以着重对优惠券的过程进行测试。

首先测试在通话过程中，服务器怎么识别用户的，测试cookie，首先登录账户，然后添加一个商品到购物车。有cookie时，发现购物车中有东西

无cookie时，发现购物车为空

说明验证用户的状态是通过cookie的。这表明存在碰撞的可能性。

请注意，在首次应用折扣代码和数据库更新，反映已经执行此操作之间可能存在竞争窗口。

首先测试优惠券的数据包，发现若已经使用的话，再次发送数据包，会提示，优惠券已经使用。使用repeater的组功能，在优惠券的数据包处，复制多个数据包，如19个，然后添加到一个组中

然后设置组中数据的发送方式以顺序进行测试

每一个数据包的回应都是，优惠券已经使用

所以按照顺序的方式很明显本来就是不行，会检测到的，因为从时间上来说，是可以被检测的，那么尝试并行测试，20个数据包一起向服务器发送，假设每个数据包之间仅仅只差0.00001毫秒，当第一个数据包到的时候，服务器开始处理并进行响应，但是这个时候又有很多的数据包是一样的操作，服务器对这20个数据包进行响应，而且进行优惠券的检测的时候，发现优惠券都是没有使用的状态，所以导致20个数据包的响应都是初次使用优惠券。

可以看到，并行发送的时候，有的可以，有的不行，因为服务器对每个数据包的响应时间可能不同导致的，这仅仅只是20个数据包，就有7个是初次使用的返回，再次重新使用优惠券的数据包，进行再次尝试。这次竟然有15个数据包成功，这就导致折扣反复的使用，最终降低到很低甚至为0。因为数据包太多了，不好截图，可以自己进行测试。不过首先要确定是有竞争的可能性。

这里先了解竞争条件，后面再进行学习，因为涉及的东西很复杂