Черные списки сценарий не выигрыша. Это может только защитить вас от известных угроз. Любой инструмент сканирования кода, который вы используете здесь, будет продолжать сообщать об этой уязвимости ... потому что черный список - это уязвимость. Смотрите эту записку от OWASP:
Этой стратегией, известной также как «негативный» или проверки «черного списка» является слабой альтернативой положительной проверки. По сути, если вы не ожидаете увидеть такие символы, как% 3f или JavaScript или аналогичные, отклоните строки , содержащие их. Это опасная стратегия, потому что набор возможных плохих данных потенциально бесконечен. Принятие этой стратегии означает, что вам нужно будет сохранить список «известных плохих» символов и шаблонов навсегда, и по определению у вас будет неполной защиты.
Кроме того, кодировка символов и ОС также создают проблему. Предположим, мы принимаем загрузку файла * .docx. Здесь рассмотрим разные угловые случаи, и это будет для каждого приложения в вашем портфолио.
- Является ли принимающее приложение запущенным на платформе linux или платформе NT? (Разделители файлов:
\ в Windows и / в linux.) a. пробелы также обрабатываются по-разному в файлах/каталогах в разных системах.
- Имеет ли приложение уже учетную запись для URL-кодирования?
- Отправляется ли файл в базу данных или в систему?
- Является ли файл, который вы получаете исполняемый файл или нет? Например, если я переименую
netcat.exe в foo.docx, действительно ли ваше приложение проверяет, содержит ли загружаемый файл magic numbers для exe-файла?
- Я могу продолжать. Но я не буду. Я мог бы написать энциклопедию.
Если это касается нескольких приложений в отношении портфеля вашей компании, то ваша этическая обязанность заключается в том, чтобы четко заявить об этом, а затем вашей компании необходимо принести белый список приложений/приложений/приложений.
Что касается ESAPI, вы должны использовать Validator.getValidInput() с регулярным выражением, которое было OR всех файлов, которые вы хотели отклонить, т.е. в validation.properties вы бы сделали что-то вроде: Validator.blackListsAreABadIdea=regex1|regex2|regex3|regex4
Обратите внимание, что штраф за штраф за черные списки тоже выше ...каждая строка ввода должна запускаться против КАЖДОГО регулярного выражения в вашем черном списке, что, как указывает OWASP, может быть бесконечным.
Итак, правильное решение состоит в том, чтобы каждая команда приложений в вашем портфолио создала белый список для их применения. Если это действительно невозможно (и я сомневаюсь в этом), то вам нужно убедиться, что вы четко указали на риски, приведенные здесь, руководству, и вы отказываетесь от использования подхода «черный список», пока не получите письменную документацию, которую компания выбирает принять риск. Это защитит вас от юридической ответственности, если черный список не удастся, и вас привлекут к суду.
[EDIT]
метод вы ищете называли HTTPUtilites.safeFileUpload()listed here as acceptance criteria, но это, скорее всего, никогда не реализуется из-за трудностей, я опубликовал выше. Черные списки чрезвычайно пользовательских приложений. Лучшее, что вы получите это метод HTTPUtilities.getFileUploads() который использует список, определенный в ESAPI.properties под ключом HttpUtilities.ApprovedUploadExtensions
Однако, версия по умолчанию должна быть настроена как я сомневаюсь, что вы хотите, чтобы пользователи загрузку .class файлов и dll к вашей системе.
Также примечание: Этот раствор является whitelist и НЕ blacklist.