Неделя, обнажившая системную ошибку

Три хостинг-провайдера за одну неделю раскрыли критические уязвимости в функционале загрузки файлов. Исследователи в области безопасности сразу обратили внимание на тревожную деталь: все три проблемы возникли из-за одного и того же подхода — проверки файлов по остаточному принципу.

Это не новая история. Паттерн повторяется из раза в раз, а ставки растут: миллионы на устранение последствий, репутационные потери, судебные иски.

Что значит "валидация по остаточному принципу"

Когда разработчик реализует загрузку файлов, часто выбирается путь наименьшего сопротивления. Проверил расширение — вроде нормально. Убедился, что MIME-тип подходящий — значит безопасно. Убедился в допустимом размере — можно сохранять.

Ни одна из этих проверок не является ошибкой сама по себе. Проблема в том, что на этом всё и заканчивается.

Суть подхода — сделать минимум и успокоиться. Как если бы вы смотрели на посылку и решали: выглядит нормально, пойдёт. А ведь внутри может быть что угодно.

Именно здесь атакующие находят лазейку. Они давно научились создавать файлы, которые проходят поверхностные проверки, но при этом содержат вредоносный код.

Анатомия уязвимости

Независимые друг от друга уязвимости, обнаруженные на прошлой неделе, имели схожую структуру:

1. Слабая проверка расширений — файлы принимались с двойными расширениями (malicious.php.jpg) или малоизвестными исполняемыми форматами (.phtml, .phar)

2. Отсутствие проверки содержимого — структура файла никогда не анализировалась, что позволяло загружать "полиглоты" — файлы, выглядящие как изображения, но выполняющиеся как код

3. Небезопасное хранение — загруженные файлы попадали в директории, доступные через веб, без должных ограничений

4. Никакой защиты от исполнения — конфигурация сервера не блокировала выполнение загруженного контента

Вместе эти недочёты означали следующее: атакующий без авторизации мог загрузить файл и выполнить произвольный код. Полный контроль над сервером.

Почему разработчики продолжают ошибаться

Разобраться в причинах важнее, чем просто зафиксировать проблему.

Дедлайны давят. В продакшене нужна быстрая выкатка. Полноценная валидация воспринимается как избыточная роскошь, особенно когда "расширение в тестах отрабатывает нормально".

Ложная уверенность. Тестовые среды обычно заполнены чистыми файлами. Все проверки зелёные — значит можно деплоить. Реальные данные покажут совсем другую картину.

Недостаток понимания угроз. Далеко не каждый разработчик имеет бэкграунд в безопасности. Многие не представляют, насколько изобретательно атакующие могут манипулировать файлами.

Уверенность, что защита есть где-то ещё. Команды иногда полагают, что WAF или харденинг сервера решит вопросы. Это опасное заблуждение.

Как должно быть: защита загрузки файлов по-настоящему

Надёжная валидация — это многоуровневая оборона. Вот правильный подход:

1. Определяйте тип по содержимому, не по расширению

# Плохо - доверяем пользовательским данным
if file.filename.endswith('.jpg'):
    save_file(file)

# Хорошо - проверяем реальное содержимое
import magic

mime_type = magic.from_buffer(file.read(1024), mime=True)
file.seek(0)  # Сбрасываем позицию буфера

if mime_type in ALLOWED_MIME_TYPES:
    save_file(file)

Используйте библиотеки вроде python-magic или libmagic. Они анализируют байтовую структуру файла, а не доверяют расширению или заявленному типу.

2. Генерируйте безопасные имена файлов

Никогда не используйте оригинальное имя файла из загрузки:

import uuid
import os

# Убираем всё и создаём защищённое имя
secure_filename = f"{uuid.uuid4().hex}.{allowed_extension}"
filepath = os.path.join(UPLOAD_DIR, secure_filename)

3. Храните файлы за пределами веб-рута

Для чувствительных приложений это обязательно. Если доступ всё же нужен — отдавайте файлы через скрипт, который проверяет авторизацию и не раскрывает реальный путь.

4. Настройте сервер на блокировку исполнения

В конфигурации веб-сервера:

# Apache - запрещаем исполнение скриптов в директории загрузок
<Directory "/var/www/uploads">
    <FilesMatch "\.(php|phtml|phar|py|pl|exe)$">
        Order Deny,Allow
        Deny from all
    </FilesMatch>
</Directory>

5. Добавьте дополнительные слои проверки

• Верификация сигнатуры файла — проверяйте "магические байты" в начале файла
• Санитизация изображений — перекодируйте картинки через безопасные библиотеки (ImageMagick), чтобы вырезать встроенный код
• Лимиты на размер — ограничивайте не только размер файла, но и размеры для изображений
• Rate limiting — не давайте атакующему загружать файлы сериями

Человеческая цена экономии на валидации

За техническими деталями стоят реальные люди:

• Клиенты, чьи данные оказываются скомпрометированы
• Бизнесы, получающие штрафы регуляторов и судебные иски
• Разработчики, чья репутация страдает из-за предотвратимых ошибок
• Пользователи, доверившиеся сервисам, которые их подвели

Безопасность — это не фича. Это ответственность.

Что делать хостинг-провайдерам

Если вы управляете хостинг-платформой или разрабатываете функционал загрузки:

1. Проведите аудит кода на предмет остаточных проверок
2. Внедрите полноценную верификацию содержимого
3. Вынесите загруженные файлы за пределы веб-доступа
4. Добавьте правила WAF как дополнительный слой защиты
5. Создайте план реагирования на инциденты
6. Инвестируйте в обучение команды разработки

Заключение

Уязвимости той недели не были результатом сложных атак или неизвестных эксплойтов. Это были последствия срезанных углов при разработке.

И это хорошая новость: значит, исправления находятся в зоне нашей досягаемости.

Безопасность не обязательно должна быть медленной или болезненной. Нужно просто перейти от "сойдёт и так" к комплексному многоуровневому подходу.

Вопрос не в том, будет ли ваше приложение проверено. Вопрос в том, пройдёт ли оно проверку.

Потратьте время на правильную валидацию. Ваши пользователи на вас рассчитывают.

Сталкивались с проверками "для галочки" в своих проектах? Расскажите в комментариях.