Ниже — развернённый, практически ориентированный разбор инцидента и план восстановления/предотвращения. Разделён на: какие уязвимости эксплуатировались, немедленные меры по восстановлению и расследованию, и долгосрочные практики разработки и политики безопасности.

1) Какие уязвимости и как они эксплуатировались

Неконтролируемая загрузка файлов (Unrestricted File Upload)
Отсутствие серверной проверки типа/содержимого загружаемых файлов (только клиентская проверка легко обходится).Сохранение файла с оригинальным именем (без санитизации)
Позволяет path traversal (../) или перезапись существующих файлов; делает имена предсказуемыми для скачивания/перехвата.Загрузка в доступную область webroot и/или с исполняемыми расширениями
Если загрузить, например, webshell.php и он сохраняется в директории, откуда сервер исполняет PHP — злоумышленник получает RCE через HTTP.Отсутствие проверки "магических" байтов (content sniffing): Content-Type можно подделать, поэтому проверка только MIME заголовка недостаточна.Недостаточные права доступа к директории загрузок (исполнение разрешено; права владельца/группы избыточны).Отсутствие антивирус/мальваре-сканирования, мониторинга и алертов.Отсутствие ограничений аутентификации/авторизации на endpoint загрузки (возможно, анонимная загрузка).Отсутствие логирования/корреляции событий (трудности с обнаружением/расследованием).

Типичная цепочка атаки:

Загрузить файл с вебшеллом (php/aspx/jsp) либо HTML/JS/SVG, либо файл с двойным расширением (image.jpg.php).Доступ к файлу через URL — выполнение кода/инъекция/кража сесий/сканирование файловой системы.Эксплуатация для чтения/скачивания файлов пользователей, установки бэкдоров, движения по сети.

2) Немедленные (containment) и первичные шаги по восстановлению и расследованию
Сразу после подтверждения компрометации:
A. Контеймент (сделать быстро)

При возможности перевести приложение в maintenance mode или временно отключить загрузку файлов (деактивировать endpoint).Изолировать затронутый хост/контейнер от сети (если есть подозрение на дальнейшее движение злоумышленника).Отключить выполнение скриптов в директории загрузок (nginx/apache/IIS) — немедленно.Перекрыть публичный доступ к upload-папке (если нельзя выключить — запретить доступ к исполняемым расширениям).

B. Сбор и сохранение доказательств (forensics)

Сделать форензическую копию диска/файлов (если потребуется расследование/правовые действия).Сохранить web-логи, access и error логи, логи приложений, базы данных, журналы аутентификации.Сохранить подозрительные файлы (хеши, копии) отдельно.

C. Оперативное выявление и удаление следов

Поиск подозрительных/новых файлов: примеры команд (либо запрос в SIEM):
find /var/www -type f -mtime -7 -exec ls -l {} \;find /var/www/uploads -type f ( -iname ".php" -o -iname ".phtml" -o -iname ".jsp" -o -iname ".aspx" )Поиск webshell-паттернов (eval, base64_decode, system, passthru, shell_exec, preg_replace//e):
grep -R --exclude-dir=vendor -nE "base64_decode|eval(|shell_exec|system(|passthru(" /var/wwwУдалить/изолировать подтверждённые webshell'ы; но не делать "поверхностное" удаление, пока не собраны доказательства.

D. Очистка и восстановление

Если компрометация ограничена приложением — удалить заражённые файлы, внедрить патчи и безопасные настройки (см. ниже).Если есть подозрение на глубокую компрометацию хоста (rootkit, новые пользователи, изменённые бинарники), лучше пересоздать/восстановить систему из надёжного образа/бекапа и заменить секреты.Сменить пароли/ключи/токены, которые могли быть скомпрометированы (все сервисные аккаунты, DB-пароли, ключи деплоя, API-токены).Инвалидировать активные сессии пользователей (если были скомпрометированы сессии).Провести сканирование всего хранилища на наличие бэкдоров и инжектов (AV + ручной аудит).

E. Оповещение

Уведомить руководство и, при необходимости, пользователей о бреши безопасности в соответствии с юридическими/регуляторными требованиями.Рассмотреть уведомление компетентных органов при значительных утечках.

3) Законы/регламенты и доказательства

Если требуется юридическое расследование: сохраните неизменный образ диска, metadata, временные метки логов. Подготовьте chain-of-custody.

4) Что нужно обязательно исправить (практические меры)

Отключить исполнение кода в директории загрузок:
Nginx: в location /uploads/ запретить обработчики PHP, отдавать файлы как статические и/или возвращать 404 для исполняемых расширений.Apache: в .htaccess или конфиге DisableEngine для этой директории (php_admin_flag engine off).Переместить хранение загруженных файлов вне webroot (например, /var/uploads) либо хранить в облачном хранилище (S3) без публичного доступа и отдавать через проксирующий контролируемый endpoint.Настроить файловую систему и права:
Файлы — режим 0644, директории 0755, владелец — отдельный непривилегированный пользователь (не root).Запретить execute (chmod -R a-x /path/to/uploads).Генерировать уникальные имена (UUID) вместо оригинальных имён; хранить исходное имя в метаданных/БД (для отображения), но не как имя файла.Санитизация имён: удаление/экранирование path-separators, контролировать кодировку, запрещать служебные символы, ограничивать длину.Серверная проверка типа файлов:
Whitelist по расширениям + проверка content-type на сервере + проверка "магических" байтов/сигнатуры (например, libmagic).Для изображений — дополнительно валидировать/пересоздавать изображение через библиотеку (ImageMagick/Libvips) — это переписывает файл в безопасный формат.Валидировать и ограничивать размер файлов; выставлять quota и лимиты.Сканирование на malware при загрузке (ClamAV, коммерческие решения) и асинхронное повторное сканирование.Блокировка двойных расширений и подозрительных сочетаний (.jpg.php).Ограничение доступа к endpoint загрузки: требовать аутентификацию и авторизацию; добавить CSRF-защиту; при необходимости CAPTCHA.Разграничение зон: отдавать загруженные файлы с отдельного домена/субдомена без cookie (cookie-less domain), с жесткой CSP и без возможности исполнять JS.Content-Disposition: attachment для выдачи файлов, чтобы избежать прямого отображения HTML/JS внутри браузера; при отдаче установить безопасный Content-Type.Логи и мониторинг: логировать все загрузки (IP, user-agent, хеш файла, имя, время), настроить алерты на аномальную активность и на загрузку исполняемых расширений.WAF и правило блокировки upload-паттернов.Тестирование: автоматические unit/integration тесты для функционала загрузки, статический анализ, SAST/DAST/PenTest.

5) Практические примеры безопасной реализации (ключевые пункты)

Серверная валидация:
Разрешать только заранее понятный набор типов (например, .png, .jpg, .pdf).Проверять mime/type и магические байты (file command/libmagic).Сохранение:
filename = UUID() + "." + canonical_extensionfilesystem_path outside webroot, permissions 0644Отдача:
Файлы выдавать через контролируемый endpoint, который потихоньку читает и отдает файл с безопасными заголовками или отдаёт временные pre-signed URL (S3) с ограниченным TTL.Пример высокой безопасности для изображений: если ожидается изображение — переписать/ре-сжать через библиотеку (создать новый файл), отбросить метаданные EXIF.

6) Политики и процессы (организационный уровень)

Внедрить Secure SDLC: threat modeling для функционала загрузки, code review для похожих участков, SAST/DAST.Обязательные ревью и тестирование критичных фич (загрузка файлов).Регулярные pentest/редтим-упражнения и проверки конфигураций серверов.Управление секретами и регулярная ротация ключей.Бэкапы и план восстановления с тестированием restore.Политика реагирования на инциденты, playbook для подобных случаев.Обучение разработчиков и админов по безопасной работе с файловыми входными данными.

7) Контрольный список для внедрения (приоритеты)
Срочно (24–72 ч)

Отключить/ограничить upload endpoint или выключить исполнение в папке uploads.Переместить файлы вне webroot или закрыть доступ.Просканировать и удалить/изолировать webshell'ы, собрать логи.Сменить скомпрометированные секреты.
Среднесрочно (недели)Реализовать серверную валидацию + магические байты + антивирус.Генерация уникальных имён и санитизация.Ограничение размера, аутентификация/авторизация, CSRF.
ДолгосрочноАрхитектурные изменения (отдельный домен/специальное хранилище, CDN с OAI).Внедрение SDLC, регулярный pentest, мониторинг/алерты.

8) Примеры конфигураций/команд

Запрет исполнения в nginx (пример идеи):
location /uploads/ { internal; try_files $uri =404; }В конфиге сервера — не передавать PHP-обработчику запросы из /uploads.Для S3: bucket private + presigned URLs, запрещённый public-read.

9) Поиск индикаторов компрометации (IoCs)

Необычные POST на upload endpoint с User-Agent редкими/поддельными.Запросы к загруженным файлам с упоминанием .php, .phtml, .aspx, .jsp.Созданные файлы с подозрительными содержимым (base64, eval).Сессии, IP, которые скачивали массово пользовательские файлы.

10) Рекомендация по проверке безопасности после чистки

Провести независимый penetration test по upload-функционалу.Проверить логи на продолжительное присутствие злоумышленника.Проводить мониторинг и регулярные ревью прав доступа.

Если хотите, могу:

1) Составить пошаговый playbook/скрипт для расследования и очистки конкретно по вашей инфраструктуре (укажите ОС, веб-сервер, язык приложения, где хранятся файлы).2) Привести короткие примеры кода (на Python/Node/Java) безопасного приема и сохранения файлов.3) Сформировать шаблон политики для загрузки файлов для команды разработчиков.

Сообщите, какие технологии вы используете (веб-сервер, язык, где хранятся файлы), и дам конкретный план восстановления и примеры конфигураций.