VB.Net 中 File.Copy 方法中的 IBM AppScan Security PathTraversal 问题

Posted 2023-02-19

【中文标题】VB.Net 中 File.Copy 方法中的 IBM AppScan Security PathTraversal 问题

【英文标题】：IBM AppScan Security PathTraversal issue in File.Copy method in VB.Net

【发布时间】：2017-01-26 22:32:34

【问题描述】：

我在 VB.Net 源上运行 IBM AppScan 工具。我在路径遍历类别下的 File.Copy 方法中遇到一个安全问题。

问题详情 - 漏洞类型 - PathTraversal 此 API 接受目录、文件名或两者。如果使用用户提供的数据来创建文件路径，则可以操纵该路径以指向不应被允许访问或可能包含恶意数据或代码的目录和文件。

我该如何解决这个问题？

Imports System.Web.Security.AntiXss
Private Function ProcessFile() As Boolean
    Dim drive As String = String.Empty
    Dim folder As String = String.Empty
    Dim filename As String = String.Empty
    Dim sourcePath As String = String.Empty
    Dim destinationPath As String = String.Empty
    drive = AntiXssEncoder.XmlEncode(String.Format("0", System.Configuration.ConfigurationManager.AppSettings("Drive").ToString()))
    folder = AntiXssEncoder.XmlEncode(String.Format("0", System.Configuration.ConfigurationManager.AppSettings("Folder").ToString()))
    filename = AntiXssEncoder.XmlEncode(String.Format("0", System.Configuration.ConfigurationManager.AppSettings("File").ToString()))

    sourcePath = Path.Combine(drive, folder, filename)
    destinationPath = Path.Combine(drive, folder, "text2.txt")

    Try
        If sourcePath.IndexOfAny(Path.GetInvalidPathChars()) = -1 AndAlso destinationPath.IndexOfAny(Path.GetInvalidPathChars()) = -1 Then
            File.Copy(sourcePath, destinationPath, True)
            Return True
        Else
            Return False
        End If

    Catch ex As Exception
        Return False
    End Try
End Function

【参考方案1】：

System.Configuration.ConfigurationManager.AppSettings 可以被认为是一个安全的来源，你可以排除发现，这样它就不会再次出现。

另一方面，此代码可被视为安全编码实践不佳。如果您将“System.Configuration.ConfigurationManager.AppSettings”替换为类似 Web UI 输入的内容，则最终用户可以控制“文件夹”、“驱动器”和“文件名”的值，这将成为一个严重的路径遍历问题。

【参考方案2】：

它可能认为 AppSettings 是不受信任的用户输入（我已经看到 AppScan Source 与 Java 项目上的配置类似），因此它抱怨您正在使用可能包含分隔符的不受信任的输入创建路径。

如果drive、folder 和filename 中的任何一个确实来自不受信任，这肯定是个问题。但是，假设您的配置只能由受信任的管理员访问，这没什么。将配置视为未经检查的来源是非常愚蠢的，但是一般来说，污点跟踪工具非常愚蠢。

这里对文件名的处理相当古怪。在使用 XML 编码文件名之前似乎不太可能是个好主意。 ToString 和 Format 步骤完全是多余的；并且检查“无效”字符的整个路径并不能防止从单个部分进行注入。这些东西是试图绕过 AppScan 吗？ InvalidPathChars 检查无济于事，因为它不直接编码/验证并返回受污染的值，并且 XmlEncode 仅在该函数被显式标记为验证/编码函数时才有帮助。

为了满足静态分析器的钝器而使代码更加破碎是可悲的。您能否添加一个函数以用作 AppSettings 值的包装器并告诉 AppScan 它是一个验证/编码函数，因此它认为这些值没有被污染？或者只是忽略/沉默虚假警告？