Проблема IBM PathScan Security PathTraversal в методе File.Copy в VB.Net

Question

Я запустил инструмент IBM AppScan на источнике VB.Net. У меня возникает одна проблема безопасности в методе File.Copy в категории Path Traversal.

Сведения о проблеме - Тип уязвимости - 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

Answer 1

Это, вероятно, учитывая AppSettings быть ненадежным пользовательским вводом (я видел, что AppScan Source делает то же самое с config в проекте Java), поэтому жалуется, что вы делаете путь с ненадежным вводом, в котором могут быть разделители.

Если какой-либо из drive, folder а также filename действительно из ненадежных, это определенно будет проблемой. Однако при условии, что ваша конфигурация доступна только доверенным администраторам, это ничего. Довольно глупо, что конфиг обрабатывается как непроверенный источник, но в целом инструменты отслеживания заражений довольно глупы.

Обработка имен файлов здесь довольно дурацкая. Кажется очень маловероятным, что имена файлов в кодировке XML перед их использованием - хорошая идея; ToString а также Format шаги совершенно лишние; и проверка всего пути на наличие "недопустимых" символов в любом случае не защищает от внедрения из отдельной части. Является ли этот материал попыткой обойти AppScan? Проверка InvalidPathChars не поможет, так как она не кодирует / проверяет напрямую и не возвращает испорченное значение, а XmlEncode поможет, только если эта функция была явно помечена как функция проверки / кодирования.

Грустно делать код более испорченным в попытке удовлетворить тупой инструмент статического анализатора. Не могли бы вы добавить функцию, которая будет использоваться в качестве оболочки AppSettings значения и сказать AppScan, что это функция проверки / кодирования, так что он не думает, что значения испорчены? Или просто игнорировать / заставить замолчать поддельное предупреждение?

Answer 2

System.Configuration.ConfigurationManager.AppSettings можно рассматривать как безопасный источник, вы можете просто исключить результаты, чтобы они больше не появлялись.

С другой стороны, этот код может рассматриваться как имеющий плохую практику безопасного кодирования. Если вы замените "System.Configuration.ConfigurationManager.AppSettings" на что-то вроде ввода веб-интерфейса, то конечный пользователь сможет контролировать значения "папка", "диск" и "имя файла", что станет серьезной проблемой обхода пути.