利用客户端路径遍历执行跨站请求伪造 - 介绍CSPT2CSRF
2024年7月2日 - Maxence Schmitt发布
为了给用户提供更安全的浏览体验，IETF提案"渐进式改进Cookie"推动了一些重要变更来解决跨站请求伪造和其他客户端问题。随后，Chrome和其他主流浏览器实施了建议的更改并引入了SameSite属性。SameSite有助于缓解CSRF，但这是否意味着CSRF已经消亡？
在审计主流Web应用程序时，我们意识到客户端路径遍历实际上可以被利用来"复活"CSRF，让所有渗透测试人员感到欣喜。
客户端路径遍历
每位安全研究人员都应该知道什么是路径遍历。这种漏洞使攻击者能够使用类似../../../../的有效载荷来读取预期目录之外的数据。与从服务器读取文件的服务器端路径遍历攻击不同，客户端路径遍历攻击专注于利用此弱点向非预期的API端点发出请求。
虽然这类漏洞在服务器端非常常见，但只有少数客户端路径遍历案例被广泛公开。我们发现的首个参考是Philippe Harewood在Facebook漏洞赏金计划中报告的错误。
客户端路径遍历执行跨站请求伪造
这项研究源于我们在Web安全评估中利用多个客户端路径遍历漏洞的经验。然而，我们意识到缺乏文档和知识来理解使用客户端路径遍历执行CSRF的局限性和潜在影响。
来源
在研究过程中，我们发现存在一个常见的偏见。研究人员可能认为用户输入必须在前端。然而，与XSS类似，任何用户输入都可能导致CSPT：
- URL片段
- URL查询
- 路径参数
- 注入数据库的数据
评估来源时，还应考虑是否需要任何操作来触发漏洞，或者是否在页面加载时触发。
接收器
CSPT将重新路由合法的API请求。因此，攻击者可能无法控制HTTP方法、标头和请求正文。所有这些限制都与来源相关。实际上，相同的前端可能具有执行不同操作的不同来源。
具有GET接收器的CSPT2CSRF
利用具有GET接收器的CSPT的一些场景存在：
- 使用开放重定向泄露与来源关联的敏感数据
- 使用开放重定向加载恶意数据以触发XSS
然而，现在许多安全研究人员都在寻找开放重定向，在使用现代框架的前端中找到XSS可能很困难。
也就是说，在我们的研究中，即使阶段更改操作没有直接通过GET接收器实现，我们也经常能够通过CSPT2CSRF利用它们，而无需具备前面两个先决条件。
实际上，通常可以将具有GET接收器的CSPT2CSRF与另一个状态更改的CSPT2CSRF链接起来。
第一原语：GET CSPT2CSRF：
- 来源：查询中的id参数
- 接收器：API上的GET请求
第二原语：POST CSPT2CSRF：
- 来源：JSON数据中的id
- 接收器：API上的POST请求
要链接这些原语，必须找到GET接收器小工具，并且攻击者必须控制返回JSON的id。在白皮书中，我们通过Mattermost中的示例解释了此场景。
与社区分享
这项研究上周由Maxence Schmitt在OWASP Global Appsec Lisbon 2024上展示。幻灯片可以在此处找到。
这篇博客文章只是我们广泛研究的一瞥。随着这份白皮书，我们发布了一个BURP扩展来查找客户端路径遍历。
结论
我们认为CSPT2CSRF被许多安全研究人员忽视，并且大多数前端开发人员都不知道。我们希望这项工作能够突出显示这类漏洞，并帮助安全研究人员和防御者保护现代应用程序。
更多信息
如果您想了解我们其他研究的更多信息，请查看我们的博客，在X上关注我们，或者随时通过info@doyensec.com与我们联系，了解更多关于我们如何帮助您的组织"安全构建"的信息。
更多精彩内容 请关注我的个人公众号 公众号（办公AI智能小助手）
对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号（网络安全技术点滴分享）
公众号二维码
公众号二维码
