一个文件上传漏洞靶场
靶机说明：
步骤Web应用程序是一组轮询的背景图像，同时它也允许上传自己图像。
检测内容
首先页面本身没有透露什么太有趣的内容。那就从模糊测试开始，看看能不能找到更多内容：
ffuf -w /usr/share/wordlists/dirb/big.txt -u http://jewel.uploadvulns.thm/FUZZ
果然成功找到了更多的目录。快速浏览一下 CSS，你就会发现旋转的背景图像是从目录/content/中获取的。该目录/admin/显示一条注释，这就说明可以在这里激活一些模块。
其他目录并没有显示出其他什么有用的内容。
检测使用的技术
下一步是找出页面使用了什么技术，同时看看它们可能引用了哪些模块类型。因此我用Wappalyzer检查了一下页面：
这里显示出来的是在Express框架上运行的node.js应用程序。
在子目录中查找内容
接下来我检查子目录去查找其他内容。提供的单词列表中的命名模式与图像的命名模式匹配，因此我也使用该列表检查/content/目录。
ffuf -w ./UploadVulnsWordlist.txt -u http://jewel.uploadvulns.thm/content/FUZZ.jpg
果然，它找到了四个用作背景的图像。
获取反向shell的脚本
因为我知道该应用程序是一个Node.js应用程序，所以我从PayloadsAllTheThings那里得到了一个反向shell，并更改了IP /端口来匹配自己服务器：
上传shell
本来想说尝试上传脚本，但它被阻止了。不过这是一个由JavaScript触发的消息，因此我使用Burp历史记录来检查加载的脚本文件。
然后我就找到了罪魁祸首，客户端验证代码：/assets/js/upload.js
如果要拦截JavaScript文件，我需要更改代理选项以拦截JS文件，因为默认情况下Burp Proxy是不会拦截它们的：
删除条件^.js$后，使用Ctrl-F5重新加载页面来实现强制完全刷新。
当upload.js请求被拦截时，再指示Burp拦截其响应（Do Intercept->Response to this request）并删除上面标记的行。
虽然我已经试图重新上传了，但它还是失败了，这次是在服务器端完成的验证。
在理想情况下，服务器应执行客户端执行的所有验证。毕竟客户端验证只是为了可用性。最终的安全性只能通过服务器端验证来提供。
不过现实很骨感，服务器执行了其他验证。我将文件扩展名更改为jpg并重试上传。这一次它成功了。
查找已上传的shell
我刚刚上传的文件在任何目录中都找不到其已知文件名。然后我使用提供的单词列表重新运行目录的模糊测试。
这一次，我在那里找到了一个额外的文件：
获取反向shell
在/admin/页面上，我可以激活/modules/目录中的模块，服务器应该强制它不接受任何其他位置。
我刚刚上传的文件位于/content/ .不过可能没有适当的验证来防止路径遍历。
然后我在我的机器上启动一个监听器nc -nvlp 8888，并通过其相对路径激活模块：../content/WON.jpg
我收到的 shell 显示应用程序以 root 身份运行。因此，不需要权限提升，我可以立即获得flag：
