Новый формат
Как взламывают сайты и как защититься: SQL-инъекции и другие угрозы
Сайт взламывают не «из спортивного интереса», а ради данных, спама, редиректов на вирус или шифрования. Для владельца это простой язык: кто-то использует дыру в коде, слабый пароль или забытый плагин.
Ниже — обзор типичных угроз (в том числе SQL-инъекций) и практичная защита. Материал про оборону и восстановление, не про проведение атак. Бэкапы БД и HTTPS — смежные темы в отдельных статьях.
Какие угрозы бывают у сайта
Атаки на веб — это не один «хакерский приём», а набор сценариев: эксплуатация уязвимостей кода, подбор паролей, фишинг админки, заражение через чужой компьютер редактора, дыры в сервере и панелях.
Цель злоумышленника: данные клиентов, рассылка спама с вашего домена, SEO-спам в скрытых страницах, майнеры, шифровальщик. Для бизнеса одинаково плохо — простой, штрафы репутации и восстановление.
Типичный набор угроз:
- инъекции в БД (SQL и родственные);
- XSS и кража сессий;
- CSRF на админ-действиях;
- брутфорс и утёкшие пароли;
- уязвимые плагины/темы;
- RCE через загрузку файлов;
- скомпрометированный хостинг/FTP.
SQL-инъекции: суть без «как атаковать»
Сайт общается с базой запросами. Если пользовательский ввод склеивают в SQL строкой, злоумышленник может изменить смысл запроса. Современный код использует подготовленные выражения / ORM — данные не смешиваются с командами.
Инъекции опасны тем, что бьют по ядру: чтение/порча таблиц, иногда выход к файловой системе (зависит от СУБД и прав). Магазин с заказами и ЛК — приоритетная цель.
Защита на уровне разработки:
- только параметризованные запросы;
- минимум прав у пользователя БД приложения;
- валидация и нормализация ввода;
- актуальные драйверы и CMS;
- не светить ошибки SQL пользователю.
Другие частые векторы
XSS: вредоносный скрипт в странице, которую видят другие пользователи или админ. Брутфорс: подбор пароля админки. Устаревший плагин: готовый вход без «сложного хакерства». Фишинг: письмо «подтвердите вход» с копией панели.
Магазины дополнительно рискуют утечкой ПДн и платёжных данных — здесь важны PCI-контур платёжки, HTTPS и минимум данных на своей стороне.
Бытовые дыры:
- admin / один пароль на всё;
- FTP с паролем 2019 года;
- demo-плагины на проде;
- открытый phpMyAdmin из интернета;
- бэкапы `.sql` в `public_html`.
Если сайт уже скомпрометировали
Не «чистите глазами один файл» и не оставляйте те же пароли. Изолируйте, восстановите из проверенного бэкапа до инцидента, обновите всё, смените ключи и доступы, проверьте cron и неизвестных админов.
Сообщите хостеру при необходимости. В Вебмастере / Search Console снимите предупреждения о вредоносном ПО после очистки. Клиентам — по политике компании, если затронуты данные.
Порядок действий:
- сменить пароли панели, CMS, БД, почты, SSH;
- отозвать сессии и ключи API;
- восстановить чистый снимок;
- обновить CMS/плагины/темы;
- проверить записи cron и неизвестные пользователи;
- включить мониторинг повторного заражения.
Базовая гигиена защиты
Обновления, сильные уникальные пароли, 2FA где есть, принцип наименьших прав, регулярные бэкапы с тестом восстановления, ограничение админки по IP при возможности, WAF/антивирус хостера как доп. слой.
Меньше поверхностей атаки: неиспользуемые плагины удаляйте, staging не светите в индекс, секреты не кладите в репозиторий.
Чеклист владельца:
- CMS и плагины обновлены;
- бэкап БД+файлов вне того же диска;
- пароли разные и длинные;
- права на файлы адекватные;
- мониторинг доступности и писем вебмастеров;
- ответственный за инциденты назначен.
Связь с SEO и доверием
Поисковики помечают опасные сайты, режут переходы, требуют подтверждения. Спам-инъекции в шаблоны портят сниппеты и индексируют мусорные URL. Восстановление позиций после долгого заражения занимает время — сначала чистота и стабильность.
Безопасность — не «отдельная галочка после SEO», а условие, чтобы контент и техника вообще работали на живом домене.
После очистки смотрите:
- нет ли новых спам-URL в индексе;
- сняты ли предупреждения в панелях;
- корректны ли редиректы и главная;
- не осталось ли вредоносных скриптов в теме.
Частые вопросы
Что такое SQL-инъекция простыми словами?
Злоумышленник подсовывает в поле формы или URL фрагмент так, чтобы СУБД выполнила нежелательный запрос. Защита — параметризованные запросы, валидация ввода, обновления CMS.
HTTPS защищает от SQL-инъекций?
Нет. HTTPS шифрует канал. Инъекции и дыры в приложении — другой слой: код, ORM, права БД.
Чем опасен взлом для SEO?
Спам-страницы, вредоносные редиректы, кража контента, попадание в списки опасных сайтов, просадка доверия и трафика.
Достаточно ли антивируса на хостинге?
Полезен как часть, не как единственная мера. Нужны обновления, сильные пароли, ограничение прав, бэкапы и мониторинг.
Что сделать сразу после подозрения на взлом?
Сменить доступы, снять сайт в maintenance при необходимости, восстановить из чистого бэкапа, обновить CMS/плагины, проверить письма и вебмастеры на уведомления о вредоносах.
Нужен ли WAF?
Для магазинов и публичных форм часто да (на уровне хостинга/CDN). Не заменяет исправление уязвимого кода.
Можно ли «проверить сайт на SQL» онлайн-сканером?
Поверхностные чекеры дают намёки, не гарантию. Серьёзный аудит — у специалиста; агрессивное сканирование чужих сайтов без права — недопустимо.
Плагины WordPress — главный риск?
Часто да: забытые и непроверенные расширения. Ставьте меньше, обновляйте, удаляйте неиспользуемое, берите из доверенных источников.
Безопасность сайта под вопросом?
Проверим обновления, доступы и бэкапы — без «серых» сканеров чужих сайтов.
Обсудить задачу
