把文件切成小块上传，下列服务器一边收一边拼，关于这套逻辑本身没问题。截断出问题的上传地方在于，很多开发者默认“分片上传”就等于“安全上传”。漏洞去年某云盘爆出的描述越权覆盖漏洞就是个典型：攻击者截获自己上传分片时的请求，把分片序号改成别人的不正文件ID，服务端没校验归属关系，下列直接拿新分片覆盖了受害者文件的关于前几KB。文件头被改，截断整个文件废掉。上传这个案例里，漏洞漏洞根源不是描述分片机制本身，而是不正服务端在合并分片时丢掉了权限校验。

很多人以为截断上传就是下列“把文件截短了传上去”，这个理解偏了。真正的截断上传（Truncation Upload）攻击，核心在于利用服务端对分片序号或文件长度字段的信任，让最终合并出的文件内容与上传者意图不符。常见手法有两种：一是伪造分片序号，比如上传时分片1、2、3，攻击者把分片2的序号改成4，服务端按序合并时发现缺了2，如果逻辑是“跳过缺失继续拼”，那最终文件就少了中间一段；二是利用Content-Length或分片大小字段的整数溢出，让服务端计算出的合并偏移量错位，导致后一个分片覆盖前一个分片的部分内容。

下面这道题，四个选项里有一个描述是错的：

A. 截断上传可能造成文件内容被部分覆盖，导致文件损坏或恶意内容注入。
B. 服务端在合并分片时，应校验每个分片所属的用户和文件ID，防止越权覆盖。
C. 截断上传漏洞只能影响文件上传功能，不会波及文件下载或预览接口。
D. 对分片序号做连续性校验，并拒绝序号跳跃或重复的分片，可以缓解截断上传。

正确答案是C。C错得离谱。文件上传和下载/预览往往共用同一套文件存储和元数据。上传时被截断或覆盖的文件，下载接口返回的就是被篡改后的内容。更麻烦的是，如果预览接口支持Range请求，攻击者甚至能通过截断上传构造出特定偏移量的恶意字节，让预览服务返回被污染的数据段。某次内部渗透测试里，我们就是先利用截断上传把WebShell的字节写进一个图片文件的尾部，再通过图片预览接口的Range请求读取出来执行——上传和预览两个模块都没做分片完整性校验，链条一打通，直接拿shell。

再说一个容易踩的坑：分片合并时的临时文件清理。有些实现会把每个分片先存成临时文件，合并后删除。如果合并逻辑因为序号错乱提前返回失败，临时文件没删干净，攻击者可以反复上传同名分片，利用文件系统的时间戳或inode复用，让后续合并读到旧分片内容。这种“截断”不是长度上的，而是时间线上的。防御手段不复杂：合并前校验所有分片序号连续且唯一，合并时按序号严格排序，合并后校验最终文件的哈希与客户端声明的一致。别信客户端传过来的任何长度字段，自己算。

最后提一句，截断上传和分片上传的断点续传功能经常打架。断点续传需要记录已上传分片列表，如果这个列表存储不当（比如放在客户端localStorage里），攻击者改一下列表就能让服务端跳过某些分片。所以服务端的已上传分片状态必须持久化在服务端，并且每次合并前重新校验。别偷懒。