Безопасность
сайта

Уязвимость на сайте редко возникает сама по себе. Её создают устаревшая система управления, слабые пароли и открытые точки входа для внедрения постороннего кода. Проверка веб-ресурса показывает, откуда исходит угроза и какой объём вмешательства нужен, чтобы закрыть уязвимость.

Источники уязвимостей

Большинство уязвимостей связано с устаревшей системой управления, забытыми тестовыми скриптами и слабыми паролями администратора. Злоумышленник обычно ищет не конкретный сайт, а слабое место в распространённом движке или плагине. Автоматический запрос сканирует подряд тысячи ресурсов, и уязвимость находят раньше владельца. Базовый способ защититься — обновлять ядро сайта и убирать неиспользуемые плагины, которые чаще всего становятся точкой входа.

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

Порядок проверки

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

Метод проверки зависит от типа системы управления и от того, что сообщил хостинг или браузер пользователя. Часть случаев закрывается заменой пароля и обновлением ядра системы. Другие требуют разбора кода вручную, скрипт за скриптом, и это увеличивает объём действий. Выбор метода определяет не тип угрозы сам по себе, а то, насколько глубоко внедрение затронуло систему.

Что входит в защиту

Базовый набор мер включает обновление системы управления и плагинов, ограничение доступа по IP там, где это уместно. Права настраиваются так, чтобы обычный пользователь не мог получить доступ к административным функциям. Отдельно закрываются формы, через которые возможно внедрение постороннего кода. Управление доступом строится по ролям: администратор, редактор, пользователь с ограниченными правами.

Часть мер защищает не сам сайт, а связанные с ним сервисы. Речь о почте на домене, панели хостинга, доступе к серверу по протоколу передачи файлов. Атака нередко идёт именно через них, а не напрямую через веб-страницы. Сделать это можно без остановки сайта, если действия согласованы по порядку. Сервис уведомлений об изменении файлов помогает заметить внедрение раньше, чем его увидит браузер посетителя.

Когда проверка не подойдёт

Разовая проверка не подойдёт, если сайт уже несколько раз подвергался внедрению постороннего кода без выяснения причины. Сначала нужно найти источник, иначе ситуация повторится снова. Не подойдёт проверка и для сайта на самостоятельно написанном движке без доступа к исходному коду. Без него нельзя ни проверить систему, ни внести изменения. Такое разграничение стоит делать отдельно от обновления системы, а не одним действием.

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

Что получает владелец сайта на выходе

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

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

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

Доступ и аутентификация пользователей

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

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

Атаки трафиком на сервер

Вредоносный трафик отличается от обычных посетителей частотой запросов и повторяющимся поведением. Такой трафик злоумышленник запускает автоматически, без участия человека. Бот перебирает адреса страниц и ищет уязвимую форму, создавая нагрузку на сервер. Рост нагрузки заметен даже в тихие часы. У атаки на популярный сайт бывает миллион вариантов подобрать уязвимое место. Часть таких попыток отсекается ещё на уровне сервера, до обращения к самому сайту.

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

HTTPS и сторонние приложения

HTTPS защищает информацию при передаче между браузером и сервером, включая пароль и данные формы обратной связи. Без действующего сертификата браузер предупреждает посетителя, и доверие к сайту снижается. Адрес с HTTPS становится основным сигналом того, что сайт настроен по актуальным правилам защиты. Уровень доверия к сайту складывается не только из содержимого страниц, но и из того, насколько защищён канал передачи данных.

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

Регулярная безопасность вместо разового вмешательства

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

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

Когда регулярная защита не даёт результата

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

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

Атака на работающий сайт редко сводится к одному методу. Один запрос пробует сочетание символов в поле ввода. Другой отправляет вредоносную команду к базе данных, а третий размещает фишинговую ссылку под видом раздела сайта. Такие попытки происходят автоматически, без участия человека, и повторяются в течение долгого периода.

Зачем сайт становится целью

Взломанный сайт интересен не только данными клиента интернет-магазина. Основной интерес злоумышленника — сам ресурс. Это скрипт для массовой рассылки, площадка для фишинговой ссылки или узел, через который поисковая выдача незаметно ведёт на другой ресурс. Такой сценарий держится долго, пока команда, которая занимается сайтом, не заметит подмену.

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

SQL-инъекции и вредоносные команды к базе данных

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

Риск особенно высок там, где база хранит данные клиента напрямую: номер заказа, контактные данные, историю покупок. Определённый способ хранения данных снижает риск даже при удачной атаке: выборочное шифрование или разделение таблиц ограничивает последствия. Клиент не замечает эту настройку, но пользуется её результатом при каждом оформлении заказа.

Фишинговые ссылки и подозрительная активность

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

Решение из категории security обеспечивает контроль за добавленными разделами и сверяет их со структурой сайта, отличая реальную от подставной. Такую ссылку сложно найти визуальным просмотром структуры без сравнения с исходной картой сайта. Сравнение проводится не один раз, а с определённым интервалом, потому что фишинговый блок могут добавить снова.

Настройка решения, которое блокирует атаку

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

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

Когда сложная защита не подойдёт

Многоконтурная защита от SQL-инъекций не подойдёт статичному сайту без базы данных и без поля для приёма заявок. Атаковать через ввод там просто нечего, и такая настройка станет избыточным элементом без практической пользы. То же касается лендинга без личного кабинета и без приёма оплаты: риск такой атаки там отсутствует изначально. Такому сайту хватает точечных мер вместо расширенного контроля ввода.