Взлом сайта — это не история про хакеров в капюшонах из голливудских фильмов. Это скрипт, запущенный в три часа ночи, который обходит тысячи сайтов в поисках одной незакрытой дыры. И когда находит — владелец узнаёт об этом последним: из письма хостинга или от клиента, которому пришла фишинговая ссылка.

Разберём, какие угрозы реально существуют, как они работают и что делать, чтобы ваш сайт не стал лёгкой добычей.

SQL-инъекции — классика, которая не умирает

SQL-инъекция — одна из старейших атак, и до сих пор входит в топ по OWASP. Суть простая: злоумышленник вводит в поле формы не данные, а фрагмент SQL-запроса. Если разработчик напрямую подставляет пользовательский ввод в запрос к базе данных — всё, игра окончена.

Пример. Форма входа проверяет пользователя запросом:

SELECT * FROM users WHERE login = 'вход' AND password = 'пароль'

Если в поле логина ввести ' OR '1'='1, запрос превратится в:

SELECT * FROM users WHERE login = '' OR '1'='1' AND password = '...'

Условие '1'='1' всегда истинно — и система пустит без пароля.

Что делать:

  • Использовать параметризованные запросы (prepared statements) — это базовое требование, не опция.
  • Никогда не подставлять пользовательский ввод напрямую в SQL.
  • Ограничить права пользователя базы данных: если сайт только читает товары — незачем давать ему права на DROP TABLE.
  • Настроить WAF (Web Application Firewall) — он отсечёт большинство типовых атак на уровне трафика.

XSS — чужой скрипт на вашей странице

Cross-Site Scripting (XSS) — атака, при которой злоумышленник внедряет вредоносный JavaScript на страницу, которую видят другие пользователи. Браузер жертвы выполняет этот скрипт как доверенный — ведь он пришёл с вашего сайта.

Варианты:

  • Stored XSS — скрипт сохраняется в базе данных (например, в комментарии) и выполняется каждый раз при загрузке страницы.
  • Reflected XSS — скрипт передаётся через URL и отражается в ответе сервера.
  • DOM-based XSS — атака происходит целиком на стороне браузера, без участия сервера.

Что может сделать такой скрипт: украсть cookies сессии, перенаправить пользователя на фишинговую страницу, показать поддельную форму входа, скрытно отправить данные на сторонний сервер.

Что делать:

  • Экранировать весь пользовательский ввод перед выводом в HTML. <script> должен превращаться в &lt;script&gt;.
  • Настроить Content Security Policy (CSP) — заголовок, который указывает браузеру, с каких источников разрешено загружать скрипты.
  • Использовать флаг HttpOnly для cookies — тогда JavaScript не сможет их прочитать.
  • Не доверять данным из URL, форм и внешних API без валидации.

CSRF — действие от имени пользователя

Cross-Site Request Forgery — атака, при которой пользователь сам того не зная совершает действие на сайте. Механизм такой: жертва залогинена на banking.com, заходит на evil.com, а там скрытая форма автоматически отправляет запрос на banking.com — например, перевод денег. Браузер прикрепит cookies сессии автоматически.

Что делать:

  • Использовать CSRF-токены — уникальные одноразовые значения, которые добавляются к каждому запросу на изменение данных. Сервер проверяет токен, и чужой сайт его не знает.
  • Проверять заголовок Origin или Referer — запросы с посторонних доменов должны отклоняться.
  • Использовать атрибут SameSite=Strict или SameSite=Lax для cookies — современные браузеры не отправят их с кросс-доменных запросов.
  • Для критичных операций (удаление аккаунта, смена пароля) требовать повторный ввод пароля.

Broken Authentication — слабые места в авторизации

Неправильно реализованная аутентификация открывает прямой путь к аккаунтам пользователей. Типичные проблемы:

Слабые пароли без ограничений. Если сайт позволяет зарегистрироваться с паролем 123456 — это уже проблема. Минимальные требования: 8 символов, буквы и цифры.

Отсутствие защиты от перебора. Без rate limiting и блокировки после N неудачных попыток злоумышленник может методично перебирать пароли. Особенно это опасно с утечёнными базами паролей — атака credential stuffing работает именно так: берут миллионы пар логин/пароль из утечек и проверяют на других сайтах.

Небезопасное хранение паролей. Пароли нельзя хранить в открытом виде или в MD5. Нужны bcrypt, Argon2 или scrypt — алгоритмы, специально разработанные для хеширования паролей: медленные и с солью.

Предсказуемые токены сессий. Если session ID генерируется по предсказуемому алгоритму — его можно угадать.

Что делать:

  • Внедрить двухфакторную аутентификацию (2FA) хотя бы для администраторов.
  • Ограничить количество попыток входа: 5-10 попыток, затем капча или временная блокировка.
  • Использовать готовые библиотеки аутентификации, а не писать свою — шанс ошибиться слишком высок.
  • Проверять сессию при каждом запросе, а не только при входе.

Небезопасная конфигурация — дыры, которые открыты по умолчанию

Много взломов происходит не из-за сложных атак, а из-за ленивой настройки. Примеры:

  • phpMyAdmin открыт для всего мира по стандартному адресу /phpmyadmin.
  • Отладочный режим включён на продакшене — сервер отдаёт полные стектрейсы с путями к файлам и переменными.
  • Дефолтные учётные данные администратора: admin/admin, admin/password.
  • Листинг директорий включён — любой может увидеть структуру файлов.
  • Старая версия CMS с известными уязвимостями.

По данным исследований, около 40% успешных взломов связаны с известными уязвимостями, для которых уже существуют патчи — просто никто не обновлял.

Что делать:

  • Закрыть все административные панели от публичного доступа или защитить IP-whitelist.
  • Отключить вывод ошибок на продакшене — логировать внутри, пользователю показывать только общее сообщение.
  • Обновлять CMS, плагины и зависимости регулярно. Настроить уведомления о новых CVE.
  • Проводить аудит конфигурации после каждого деплоя.

Утечки данных — что и как защищать

Передача и хранение чувствительных данных — отдельная история. Здесь ошибаются даже опытные команды.

HTTPS — это не опция. Если сайт до сих пор работает по HTTP — данные пользователей передаются в открытом виде. Сертификат Let's Encrypt бесплатный, настраивается за час. В 2026 году браузеры активно предупреждают об HTTP-сайтах, и пользователи уходят.

Чувствительные данные в URL. Токены, пароли и идентификаторы не должны передаваться в GET-параметрах — они оседают в логах серверов, браузерной истории и реферер-заголовках.

Логи с приватными данными. Типичная ошибка: логировать весь входящий запрос целиком, включая номера карт, пароли и персональные данные. Нужно явно фильтровать то, что не должно попадать в логи.

Открытые S3-бакеты и подобное. Миллионы файлов утекло из-за того, что облачное хранилище было настроено на публичный доступ по умолчанию.

Что делать:

  • HTTPS везде, с правильными заголовками: HSTS, X-Content-Type-Options, X-Frame-Options.
  • Шифровать чувствительные данные в базе данных — не только пароли.
  • Минимизировать сбор данных: не хранить то, что не нужно.
  • Регулярно проверять настройки доступа к облачным ресурсам.

Уязвимые зависимости — риск, который приходит с npm install

Современный веб-проект тянет за собой сотни библиотек. Каждая из них — потенциальная точка входа. Достаточно вспомнить уязвимость в Log4j в 2021 году: она затронула миллионы систем по всему миру, потому что библиотека использовалась повсеместно.

Что делать:

  • Использовать npm audit, pip-audit, composer audit — автоматическую проверку зависимостей на известные CVE.
  • Интегрировать Dependabot или Snyk в CI/CD — они будут автоматически открывать PR с обновлениями безопасности.
  • Удалять неиспользуемые зависимости — они создают поверхность атаки без пользы.
  • Фиксировать версии зависимостей и проверять целостность пакетов.

Практический чек-лист для владельца сайта

Если не хочется читать про каждую уязвимость отдельно — вот минимальный набор действий:

  1. HTTPS с актуальным сертификатом.
  2. Обновлённая CMS и все плагины.
  3. Сложные пароли для всех административных аккаунтов.
  4. 2FA для администраторов.
  5. Регулярные бэкапы с проверкой восстановления.
  6. Ограничение прав доступа: пользователь базы данных не должен иметь лишних привилегий.
  7. WAF — хотя бы базовый, от вашего хостинга или Cloudflare.
  8. Мониторинг: уведомления о падении сайта и подозрительной активности.

Если сайт обрабатывает платёжные данные — добавьте пентест раз в год. Это дешевле, чем разбираться с последствиями взлома.

Что делать, если сайт уже взломали

Паниковать не нужно, но действовать нужно быстро.

Первое — изолировать. Перевести сайт в режим обслуживания, чтобы прекратить распространение вреда. Если есть подозрение на утечку данных пользователей — уведомить их.

Второе — найти точку входа. Без этого лечить бессмысленно: сайт взломают снова. Анализ логов, сравнение файлов с резервной копией, поиск посторонних файлов.

Третье — восстановить из чистого бэкапа, а не пытаться вычистить вредоносный код вручную. Зловред умеет прятаться.

Четвёртое — закрыть уязвимость, которую использовали, обновить все пароли и отозвать все сессии.

Пятое — усилить мониторинг на следующие недели: часто после взлома пробуют зайти повторно.

Безопасность в разработке, а не после

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

Правильный подход — security by design: проверка входящих данных, минимальные привилегии, шифрование чувствительных данных — всё это закладывается на этапе проектирования, а не прикручивается потом.

Когда мы в REEXY берёмся за разработку корпоративного сайта или интернет-магазина, вопросы безопасности — часть технического задания, а не отдельная опция. Это влияет на выбор стека, архитектуру работы с данными и настройку инфраструктуры.

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