Как чаще всего взламывают сайты: семь дверей, которые забывают закрыть

Когда владелец бизнеса представляет себе взлом, он часто видит что-то сложное: гениальный хакер, уязвимость нулевого дня, недели подготовки. На практике большинство инцидентов выглядит скучнее. Злоумышленник не ломает стену — он находит дверь, которую забыли закрыть. Обзоры вроде OWASP Top 10 и ежегодного Verizon Data Breach Investigations Report из года в год описывают одни и те же типовые причины.

Ниже — семь таких дверей. Для каждой — что это и как её закрыть.

1. Слабые и повторяющиеся пароли без второго фактора

Сотрудник использует один пароль для админки обменника и для форума, который утёк три года назад. Утёкшие пары «почта — пароль» автоматически проверяют на тысячах сайтов — это называется credential stuffing. Если на входе в админку нет второго фактора, такой перебор рано или поздно срабатывает.

Как закрыть. Обязательная 2FA для всех, у кого есть доступ к админке и серверам. Ограничение частоты попыток входа. Менеджер паролей вместо «одного надёжного пароля на всё».

2. Устаревшие CMS, плагины и библиотеки

Для известных уязвимостей в популярных CMS, плагинах и библиотеках существуют готовые инструменты эксплуатации. Сайт на версии двухлетней давности для автоматического сканера — лёгкая добыча, даже если его собственный код написан аккуратно.

Как закрыть. Регулярные обновления по расписанию, а не «когда будет время». Проверка зависимостей (composer audit, npm audit) в CI. Удаление плагинов и модулей, которые не используются, — их тоже нужно обновлять, а пользы от них ноль.

3. Открытые `.env`, `.git` и бэкапы

Файл .env с паролями от базы, папка .git с историей кода, архив backup.zip в корне сайта — всё это регулярно оказывается доступным по прямой ссылке. Сканеры проверяют такие пути первыми, потому что находка сразу даёт ключи от всего.

Как закрыть. Корень веб-сервера должен указывать на публичную папку приложения (в Laravel — public), а не на весь проект. Запрет доступа к скрытым файлам в nginx. Бэкапы хранятся вне веб-сервера, а лучше — на другом сервере.

4. Загрузка файлов без проверок

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

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

5. XSS и кража сессии

Межсайтовый скриптинг (XSS) — когда сайт показывает введённый пользователем текст как код. Например, комментарий к заявке, который оператор открывает в админке. Если в комментарии спрятан скрипт, он выполнится в браузере оператора — с его правами и его сессией.

Как закрыть. Экранирование всего, что выводится на страницу (шаблонизаторы вроде Blade делают это по умолчанию — важно не обходить его без необходимости). Cookie сессии с флагами HttpOnly и Secure. Заголовок Content-Security-Policy, ограничивающий, какие скрипты вообще может выполнять страница.

6. Сломанный контроль доступа: чужая заявка по номеру

Клиент открывает свою заявку по адресу с номером, меняет номер на соседний — и видит чужую заявку с реквизитами и суммой. Это называется IDOR, небезопасная прямая ссылка на объект. Похожая ошибка — когда скрытая кнопка в интерфейсе спрятана, но сам адрес действия на сервере не проверяет права.

Как закрыть. Проверка прав на сервере для каждого объекта и каждого действия: «принадлежит ли эта заявка текущему пользователю». В Laravel для этого есть политики (Policies). Непредсказуемые идентификаторы (UUID) вместо порядковых номеров — как дополнительная мера, но не замена проверке.

7. SSRF и неверно настроенные серверы

SSRF — подделка запросов со стороны сервера. Если приложение умеет «сходить по ссылке», которую передал пользователь (загрузить картинку по URL, проверить вебхук), злоумышленник может заставить сервер обратиться к внутренним ресурсам: служебным API, базе данных, панели облачного провайдера.

Рядом с этим — классические ошибки конфигурации: база данных, открытая в интернет, Redis без пароля, панель управления со стандартным логином.

Как закрыть. Для запросов по пользовательским ссылкам — белый список доменов и запрет обращений к внутренним адресам. Закрытые порты: наружу смотрят только веб-сервер и SSH, а базы данных доступны лишь внутри. Смена всех стандартных паролей при установке.

И восьмая, за пределами кода: фишинг сотрудников

Даже идеальный код не спасёт, если оператор сам введёт пароль на поддельной странице или установит «обновление», присланное в мессенджере. Технические меры здесь — 2FA с аппаратными ключами или приложениями-аутентификаторами, минимальные права для каждой роли и журнал действий в админке, чтобы необычное поведение было видно сразу.

Большинство взломов — не высокое искусство, а открытые двери. Их закрывает регулярная гигиена, а не разовый героизм.
2FA и ограничение попыток входа для всех служебных доступов.
Обновления по расписанию и проверка зависимостей в CI.
Корень сайта — только публичная папка; бэкапы и .env — вне досягаемости.
Проверка прав на сервере для каждого объекта, загрузки — без права на исполнение.
Наружу — только веб-сервер и SSH; всё остальное закрыто.