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

Я запустил инструмент 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

person Deepak    schedule 19.09.2016    source источник


Ответы (2)


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

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

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

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

person bobince    schedule 19.09.2016

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

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

person Judak    schedule 07.10.2016