os.path.basename不能防御路径遍历，因其仅字符串截断不解析语义，对../../../etc/passwd返回passwd，拼接后仍越权；必须用os.path.realpath归一化路径并校验是否落在白名单目录内。
为什么 os.path.basename 不能挡住路径遍历
直接用 os.path.basename 提取用户传入的文件名，看似“只留最后一段”，实则完全无效。它只是字符串截断，不解析路径语义——对 ../../../etc/passwd，os.path.basename 返回的仍是 passwd；后续拼接时，/var/www/uploads/ + 'passwd' 还是会落到错误位置。
更糟的是，它对 URL 编码（%2e%2e%2f）、Unicode 点号（．．／）、空字节（ ）或中间带 ./ 的变体（/a/./b/../etc/passwd）毫无抵抗能力。只要服务端做了 URL 解码（Flask/Django 默认做），攻击载荷早就在你调用 basename 前还原了。
必须用 os.path.realpath 归一化后再比对根目录
核心是让操作系统真正解析路径，再确认最终落点是否在白名单范围内。不能靠字符串操作，必须依赖路径归一化和绝对路径校验。
- 先用
os.path.join(BASE_DIR, user_input)拼出待检查路径 - 再用
os.path.realpath解析符号链接、消除../.、标准化分隔符 - 最后用
.startswith(BASE_DIR + os.sep)或os.path.commonpath判断是否仍在允许目录内
示例（Flask）：
立即学习“Python免费学习笔记（深入）”；
import os
<p>BASE_DIR = '/var/www/uploads'
filename = request.args.get('file', '')
target_path = os.path.join(BASE_DIR, filename)
real_path = os.path.realpath(target_path)</p><p>if not real_path.startswith(BASE_DIR + os.sep):
return "Access denied", 403</p><h1>安全读取</h1><p>with open(real_path, 'rb') as f:
return f.read()
上传场景下还要额外防文件名污染
用户上传文件时，原始文件名（request.files['file'].filename）同样可能含恶意路径。不能直接拼接保存。
- 永远忽略客户端传来的完整路径，只取
filename.rsplit('/', 1)[-1].rsplit('\', 1)[-1]获取纯文件名 - 强制重命名：用随机字符串 + 白名单后缀（如
uuid4().hex + '.jpg'） - 保存前仍需对目标路径做
os.path.realpath校验——哪怕你重命名了，攻击者仍可能通过Content-Disposition或 multipart boundary 注入路径
别漏掉 Windows 下的路径分隔符和驱动器盘符
在 Windows 环境中，..\、C:\、\Windows\system32\drivers\etc\hosts 都是有效绕过点。仅校验 ../ 不够。
-
os.path.realpath在 Windows 下也能正确处理\和盘符，但必须确保BASE_DIR是绝对路径（如r'C: arwwwuploads'） - 校验时用
os.path.commonpath([BASE_DIR, real_path]) == BASE_DIR比startswith更健壮，能防C:other.. arwwwuploads这类跨驱动器跳转 - 若应用部署在跨平台环境，统一用
os.path.normpath+os.path.abspath初始化BASE_DIR，避免相对路径隐患
真正安全的边界不是“过滤什么字符”，而是“最终路径是否物理落在授权目录内”。任何跳过 realpath 的方案，本质上都是在赌攻击者没试新编码——而他们总会试。
