有这么一种csrf的情况,目前来说挺少人注意到的。遇到的话可以尝试。 我们正常访问这样的url
https://ex.com/team/member/info?id=peter
访问这个连接之后，后续会发起类似这样一个请求
POST /check/member/id/peter
假如我们构造这样的链接 https://ex.com/team/member/info?id=peter/../../../fuzz 访问之后就会产生这样一个请求
POST /fuzz
如何造成危害呢，我们需要去寻找有危害的端点，通过js提取等方法发现有类似delete的接口，这里就需要自己去分析了 我们构造这样一个链接发给受害者,假设这里peter是每个用户的默认账号信息 https://ex.com/team/member/info?id=peter/../../../delete/member/id/peter 访问之后，浏览器在后续请求中发送
POST /delete/member/id/peter
就会删掉这个默认的账号信息 由于这个后续的post请求是受害者自己后续浏览器发送的，会带上csrftoken，从而绕过csrftoken的防护。 在挖掘的时候，要留意前后数据包之间的关系，注意分析每个数据包，才能发现漏洞所在。 这里讲的是一种相对简单的情况，具体数据包的构造还要具体分析。