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