Как проверить имя файла в JAVA для разрешения CWE ID 73(внешний контроль имени файла или пути) с помощью ESAPI?

Question

Я сталкиваюсь с этим недостатком безопасности в моем проекте во многих местах. У меня нет никакого белого списка, чтобы сделать проверку в каждом случае этого недостатка. Я хочу использовать вызов ESAPI, чтобы выполнить базовую проверку черного списка имени файла. Я читал, что мы можем использовать объект SafeFile ESAPI, но не могу понять, как и где.

Ниже приведены несколько вариантов, которые я придумала. Пожалуйста, дайте мне знать, какой из них сработает?

ESAPI.validator().getValidInput() или же
ESAPI.validator().getValidFileName()

Answer 1

Черные списки - беспроигрышный сценарий. Это может защитить вас только от известных угроз. Любой инструмент сканирования кода, который вы здесь используете, будет продолжать сообщать об уязвимости... потому что черный список - это уязвимость. Смотрите это примечание от OWASP:

Эта стратегия, также известная как "отрицательная" или "черный список" проверки, является слабой альтернативой положительной проверке. По сути, если вы не ожидаете увидеть символы, такие как%3f или JavaScript или аналогичные, отклоните строки, содержащие их. Это опасная стратегия, потому что набор возможных плохих данных потенциально бесконечен. Принятие этой стратегии означает, что вам придется вести список "известных плохих" персонажей и шаблонов навсегда, и вы по определению будете иметь неполную защиту.

Кроме того, кодировка символов и ОС также создает проблему. Допустим, мы принимаем загрузку файла *.docx. Вот различные угловые случаи для рассмотрения, и это будет для каждого приложения в вашем портфолио.

1. Работающее приложение работает на платформе Linux или NT? (Разделители файлов \ в Windows и / в Linux.) пробелы также обрабатываются по-разному в путях файлов / каталогов в разных системах.
2. Приложение уже учитывает кодировку URL?
3. Сохраняемый файл хранится в базе данных или в самой системе?
4. Является ли файл, который вы получаете исполняемым или нет? Например, если я переименую netcat.exe в foo.docx действительно ли ваше приложение проверяет, содержит ли загружаемый файл магические числа для исполняемого файла?
5. Я могу продолжать. Но я не буду. Я мог бы написать энциклопедию.

Если это касается нескольких приложений, относящихся к портфелю вашей компании, ваша этическая обязанность четко заявить об этом, и тогда ваша компания должна создать белый / список приложений / приложений / приложений.

Что касается ESAPI, вы должны использовать Validator.getValidInput() с регулярным выражением, которое было ИЛИ всех файлов, которые вы хотели отклонить, т.е. в validation.properties вы бы сделали что-то вроде: Validator.blackListsAreABadIdea=regex1|regex2|regex3|regex4

Обратите внимание, что штраф за синтаксический анализ для черных списков также выше... каждая входная строка должна запускаться против КАЖДОГО регулярного выражения в вашем черном списке, который, как указывает OWASP, может быть бесконечным.

Итак, еще раз, правильное решение состоит в том, чтобы каждая группа приложений в вашем портфеле создала белый список для своего приложения. If this is really impossible (and I doubt that) then you need to make sure that you've stated the risks cited here clearly to management and you refuse to proceed with the blacklist approach until you have written documentation that the company chooses to accept the risk. This will protect you from legal liability when the blacklist fails and you're taken to court.

[РЕДАКТИРОВАТЬ]

The method you're looking for was called HTTPUtilites.safeFileUpload() listed here as acceptance criteria but this was most likely never implemented due to the difficulties I posted above. Blacklists are extremely custom to the application. The best you'll get is a method HTTPUtilities.getFileUploads() which uses a list defined in ESAPI.properties under the key HttpUtilities.ApprovedUploadExtensions

However, the default version needs to be customized as I doubt you want your users uploading .class файлы и dll to your system.

Also note: This solution is a whitelist и НЕ blacklist.

Answer 2

Следующий фрагмент кода работает, чтобы обойти проблему CWE ID 73, если путь к каталогу является статическим и только имя файла контролируется извне:

      //'DIRECTORY_PATH' is the directory of the file
//'filename' variable holds the name of the file
//'myFile' variable holds reference to the file object

File dir = new File(DIRECTORY_PATH);
FileFilter fileFilter = new WildcardFileFilter(filename);
File[] files = dir.listFiles(fileFilter);
File myFile = null ;
if(files.length == 1 )
   myFile = files[0];