CSTP漏洞¶
关于Restful风格以及CSTP漏洞¶
其实这个漏洞似乎也有一年的历史了，并不算是很新的姿势，不过我最近才了解到，感觉很有意思，而且可以和很多我们熟知的老朋友漏洞结合利用，所以写一篇笔记来总结一下。首先还是看看这个词是什么意思，它的全称实际上是Client-Side Path Traversal，即“客户端路径遍历”，那么我们可以想到它其实是一个主要在客户端被利用的漏洞，这个漏洞看起来很玄乎，实际上并没有那么复杂。要了解这个漏洞的成因，首先需要知道什么是Restful风格，做WEB开发做的比较多的小伙伴，或者是挖洞挖的多的小伙伴，肯定都知道Restful风格的，简单来说它可能长成下面这样：
又或者是下面这样：
通过调用上述这样的接口，我们就可以获取到一些信息，其中，uri中的某一些特定部分实际上充当了参数名、参数值的作用，以这个/api/user/info/1 为例，在后端可能进入user这个控制器的info方法，然后分割uri，把uri中特定部分的值作为参数（一般都是在特定位置放一个占位符，自动获取），比如上面这个场景就是把末尾的1作为参数传入，这样获取到id为1的用户的信息。
现在我们知道了Restful风格是什么，平时挖洞肯定也遇见不少，一般遇到这种都很容易爽挖越权漏洞逻辑漏洞，但是这和本文主题有什么关系呢？接下来我们需要把视角转向前端。
Restful风格的接口当然不是单独使用的，很多时候都是从前端参数里捕获输入，然后放到Restful风格的接口中去做拼接，然后传到后端，我们举一个最经典的例子，你在一个网站看文章，可能经过如下三步走流程：
- 触发前端代码
例如，你可能会发现你访问了下面这样的前端uri：
显然，这是一个前端的uri，那么它具体会调用什么接口呢？
- 将前端uri中的关键信息进行提取，并调用接口
假设js中针对上述uri，调用如下后端接口：
- 后端接口返回信息并加载到前端
后端接口获取id为1337的文章的信息，返回到前端。
好的，现在我们又复习了一遍经典的网站工作流程，有一个前端uri：
以及它对应的后端接口：
那这又和本文主题有什么关系呢？这就是关键了，我们来想想，假如我们在前端uri中传入下面这样的输入：
那么此时，我们调用的后端接口会是怎样的呢？如果前端没有对我们的输入做额外处理，那么它大概率是这样的：
这个?的技巧我们在SSRF和重定向漏洞中都很常用，当uri中存在一些不得不去除的片段时，我们就可以考虑使用?或者#这类的字符去处理掉这些片段，而很多Web中间件都会对../有所处理，认为这是在进行所谓的“跨目录”，因此后端实际上收到的请求有可能变成下面这样：
（实际上有时经前端处理后就会直接变成这样，都无需进入后端）
这样，我们就借助这个前端的入参，从原本的调用/api/article/1337/details接口“逃逸”了出来，现在我们可以借助这个前端入参去尝试访问目标网站的几乎任何接口，这边借用一下别人的图片，来演示一下我们可以实现的效果：
在这种场景下，我们可以借用反序列化链中的观点，把容易受到攻击的前端uri称为Source点，把最终利用的后端uri称为sink点
你此时可能会问，这又有什么用呢？它看起来啥危害都没有呀，是的，单纯的CSPT漏洞毫无危害，但一旦它结合我们的一些老朋友进行利用，那危害就有可能变得很大了
Note
综上，可以看到其实该漏洞的本质在于以下几点：
- 前端存在可控参数且该参数要通过Js等再构造新的后端API调用
- 新的后端API必须是类似于RestFul风格的，这样才可能存在路径穿越