9.2

9.md

@@ -51,3 +51,38 @@ Shopify 是一个巨大并健壮的平台，它包含 Web UI 以及受支持的
 > 重要结论
 
 > 这里有两个重要结论。首先，并不是所有东西都涉及代码注入。始终记住使用代码并观察向站点传递了什么信息，并玩玩它看看什么会发生。这里，所有发生的事情是，移除 POST 参数来绕过安全检查。其次，再说一遍，不是所有攻击都基于 HTML 页面。API 终端始终是一个潜在的漏洞区域，所以确保你考虑并测试了它们。
+
+### 2\. 星巴克竞态条件
+
+难度：中
+
+URL：`Starbucks.com `
+
+报告链接：`http://sakurity.com/blog/2015/05/21/starbucks.html`
+
+报告日期：2015.5.21
+
+奖金：无
+
+描述：
+
+如果你不熟悉竞态条件，本质上它是两个潜在的进程彼此竞争来完成任务，基于一个厨师场景，它在请求被执行期间变得无效。换句话说，这是一个场景，其中你拥有两个进程，它们本应该是互斥的，不应该同时完成，但是因为它们几乎同时执行，它们被允许这么做了。
+
+这里是一个例子：
+
+1.  你在手机上登录进了你的银行站点，并请求将 $500 从你的一个仅仅拥有 $500 的账户转到另一个账户。
+
+2.  这个请求花费很长时间（但是仍然处理），所以你在你的笔记本上登录，并且再次执行了相同请求。
+
+3.  笔记本的请求几乎立即完成了，但是你的手机也是这样。
+
+4.  你刷新了银行账户，并发现你的账户里有 $1000。这意味着请求执行了两次，这本不应被允许，因为你一开始只拥有 $500。
+
+虽然这个很基础，理念都是一样的，一些条件存在于请求开始，在完成时，并不存在了。
+
+所以，回到这个例子，Egor 测试了从一个星巴克的卡中转账，并且发现他成功触发了竞态条件。请求使用 CURL 程序几乎同时创建。
+
+> 重要结论
+
+> 竞态条件 是个有趣的攻击向量，它有时存在于应用处理一些类型的余额的地方，例如金额、积分，以及其他。发现这些漏洞并不总是发生在第一次尝试的时候，并且可能需要执行多次重复同时的请求。这里，Egor 在成功之前执行了 6 次请求。但是要记住在测试它的时候，要注意流量负荷，避免使用连续的测试请求危害到站点。
+