下载接口常见写法是把用户提供的文件名拼到目录后面再删除 ../。这类过滤看似直观却很难覆盖编码、不同分隔符、重复解析和符号链接等情况。风险来自“最终路径”正确问题不是“输入里有没有两个点”而是“解析后的路径是否仍在允许目录内”。以 Python 为例from pathlib import Path base Path(/srv/downloads).resolve() target (base / user_name).resolve() target.relative_to(base)当 target 不属于 base 时relative_to 会抛出异常应返回通用错误而不是暴露服务器真实目录。注意这里必须在拼接后调用 resolve只对输入字符串做替换无法处理 a/../b 之类的归一化结果。符号链接同样要考虑允许目录内的文件可能是指向目录外的符号链接。resolve 能帮助发现这种最终落点但还应限制谁可以在下载目录中创建链接。上传、解压和文件管理功能如果共用同一个目录风险会更高。更稳的设计是给每个业务对象分配内部文件 ID服务端根据 ID 查询受控元数据而不是把原始文件路径暴露给客户端。这样既能避免路径计算错误也方便做权限校验、审计和文件失效处理。审计时看三处检查用户输入从哪里进入、在哪一步被解码或归一化、最终由哪个 API 打开文件。压缩包解压、模板加载、日志查看和静态文件预览也可能存在相同问题。单元测试应覆盖合法文件、..、绝对路径、URL 编码和符号链接不要只测一个显眼样例。如果你正在学习代码审计、Web 漏洞原理和防护实践可以参考马士兵网络安全课程学习入口