C# 文件系统符号链接攻击防护 C#如何避免因不当处理符号链接导致的安全漏洞

应使用 filesysteminfo.attributes 配合 reparsepoint 检查并比对 path.getfullpath 与 fileinfo.fullname 是否相等来可靠判断符号链接，而非依赖 file.getattributes(path) 返回的 fileattributes.reparsepoint。

判断路径是否为符号链接（C# File.GetAttributes 的陷阱）

windows 和 linux 上的符号链接（symlink）在 .NET 中不会自动解析，但很多 API（比如 File.Exists、Directory.GetFiles）默认会跟随链接——这正是漏洞温床。别直接信 File.GetAttributes(path) 返回的 FileAttributes.ReparsePoint：它只对目录级符号链接（junction 或 symlink 目录）稳定有效；对文件级 symlink，尤其跨卷或由非管理员创建的，可能返回 0 或误判。

• 真正可靠的方式是调用 Win32 GetFileAttributesEx（Windows）或 stat（Linux/macos），但 .NET 6+ 提供了更安全的替代：FileSystemInfo.Attributes 配合 ReparsePoint 检查 + 手动比对原始路径与解析后路径
• 示例：先用 Path.GetFullPath(path) 获取规范路径，再用 new FileInfo(path).FullName，若二者不等，大概率遇到 symlink（注意：需在相同驱动器/挂载点下比对，否则 GetFullPath 可能补全失败）
• 不要依赖 File.ReadLink（.NET 5+）——它仅对 *已知* 是 symlink 的路径有效，而你正要判断它是不是

禁止自动解析路径的 API（File.Open / Directory.EnumerateFiles 的危险模式）

这些方法默认启用符号链接跟随（follow symlinks），一旦用户可控路径含 symlink，就可能读写任意位置文件，绕过路径白名单或沙箱限制。

• File.Open(path, FileMode.Open, FileAccess.Read, FileShare.None, bufferSize, FileOptions.None)：最后一个参数 FileOptions.None 是默认值，隐式开启跟随。必须显式传入 FileOptions.OpenReparsePoint 才能打开链接本身（而非目标），再配合手动校验
• Directory.EnumerateFiles(root, pattern, SearchOption.AllDirectories)：递归时会无条件跟随所有 symlink，哪怕 root 在 C:appdata，一个指向 C:WindowsSystem32 的 symlink 就会让整个系统目录被遍历
• 解决方案不是禁用递归，而是改用 Directory.EnumerateFileSystemEntries + 逐项检查 FileSystemInfo.Attributes & FileAttributes.ReparsePoint，发现即跳过或报错

验证路径是否在预期范围内（Path.GetRelativePath 不够用）

很多人用 Path.GetRelativePath(baseDir, userInputPath) 判断是否“在目录内”，但这个函数不处理 symlink：如果 baseDir 下有个 symlink 指向 /etc/shadow，GetRelativePath 仍返回 ../etc/shadow 这种看似合法的相对路径。

• 正确做法是获取真实物理路径：Path.GetFullPath(new DirectoryInfo(userInputPath).FullName)（注意：这里 DirectoryInfo 构造函数会跟随链接，所以必须先确保 userInputPath 不含未校验的 symlink）
• 更稳妥的是用 Path.GetFullPath 后，再用 String.StartsWith 比较物理路径前缀，且必须以路径分隔符结尾（如 allowedRoot + Path.DirectorySeparatorChar），避免 C:safe 匹配到 C:safeguard
• Linux 上还要注意挂载点边界——/proc/mounts 或 stat -c "%d" . 对应的 device ID 才是真实隔离依据，仅靠路径字符串无效

.NET 版本与平台差异（FileOptions.OpenReparsePoint 在 Linux 的失效）

这个标志在 Windows 上能让你打开 symlink 文件本身，在 Linux/macOS 上却会被静默忽略（.NET Runtime issue #43921），导致你以为关掉了跟随，其实没关。

• Linux 下唯一可靠方式是用 System.IO.FileSystemWatcher 或 stat P/Invoke 检查 st_mode & S_IFLNK，再拒绝处理
• .NET 7+ 引入 File.GetLinkTarget，但它要求路径已是 symlink，不能用于前置检测；且 macOS 上部分 HFS+ 符号链接类型（如 alias）不被识别
• 跨平台服务务必把 symlink 检查逻辑下沉到启动时：用 Environment.OSVersion.Platform 分支，并在 CI 中用不同 OS 镜像跑路径遍历测试

最麻烦的不是技术实现，而是 symlink 可能藏在路径中间任意一级——比如 ./data/user/123/../@symlink/config.json，需要完整展开并逐段校验。别假设用户只会在末尾动手脚。