利用竞争条件（Race Condition）对目标Web应用实现RCE(2)

此时，毫无头绪之际，我通过burpsuite的 intruder 模式上传操作中，发现了响应长度的异常。有时候需要发起10个左右的请求，有时候则需要发起20–30个请求，才会出现这样的响应异常。正常来说，多数请求的响应长度为1147，但奇怪的是，在其中，会夹杂着长度为1710的响应。如多次上传空内容的rc.php，其请求样式为：

以下是正常的长度为1147的响应：

以下则是异常的长度为1710的响应，其中竟然返回了我们上传的php文件的本地路径：

本想着，有了这个路径，那么完全就可以实现监听反弹了，但其实不然。当我通过浏览器访问该上传php文件后，Web应用返回了“File not Found”的提示，经再次检查后发现，该文件路径已经对应成了S3存储桶的路径了，所以，因此我猜测，我们的上传文件被目标Web应用移动到云端S3之前，在Web应用服务器中保存的时间大概会是短暂的1到2秒。

根据以上的时间猜测，我就有一个想法：如果我们从客户端来触发竞争条件，通过浏览器反复请求上传文件路径，以此来争取对其的访问占有权限，这样的做法是否可行？

也就是：

在我们shell反弹服务器中设置端口监听 -> 上传我们的反弹shell文件 -> 发起多个请求执行竞争条件 -> 获取长度异常的响应 -> 从中获取上传shell文件路径并用浏览器访问并不断刷新（CTRL+R） -> 以这种方式再次让目标Web应用处于竞争条件下, 我们就占有了对上传shell文件的继续访问权。

一试，果然行。以下是触发反弹shell实现RCE的竞争条件逻辑图：

nc端监听返回的RCE结果：

在上传文件本身被转移到云端S3存储桶之前，我们有可能获得上传文件的本地路径。哪怕只有1或2秒，就足以触发上传shell的成功反弹；