Как взламывают сайты компаний и что исправить в первую очередь?

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

КОРОТКО

Как взламывают сайты на деле

Большинство сайтов компаний взламывают через обычные дыры: устаревшие плагины и фреймворки, украденные пароли администраторов, небрежную загрузку файлов, файлы и бэкапы в публичных папках, сторонние скрипты и аккаунты, которые никто не закрыл. Закрывать их стоит в таком порядке: сначала доступы, затем бэкапы и обновления, потом открытые файлы и загрузки, потом скрипты. Для типичного сайта это от 30 до 75 часов работы по нашей оценке, а дальше ежемесячная рутина.

Отчёт Verizon Data Breach Investigations Report 2026 охватывает более 22 000 подтверждённых утечек в 145 странах за период с октября 2024 года по ноябрь 2025 года. Использование уязвимости в программах стало самым частым способом проникновения: 31% утечек, против 16% у фишинга и 13% у злоупотребления учётными данными. В регионе Европа, Ближний Восток и Африка картина резче: 47% уязвимости, 28% фишинг, 6% учётные данные, так что здесь первыми стоит закрывать обновления и почту. В малом и среднем бизнесе третья сторона участвовала в 55% утечек. Эти цифры описывают все виды утечек, включая сайты, поэтому читать их стоит как направление, а не как статистику по сайтам.

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

Чтобы ваш сайт атаковали, никому не нужно выбирать именно вашу компанию.

ШЕСТЬ ПУТЕЙ

Шесть путей и что их закрывает

Эти шесть путей покрывают большую часть того, что мы проверяем, когда сайт приходит к нам:

OWASP Top 10 за 2025 год смотрит на веб-приложения со стороны кода и подтверждает ту же картину: на первом месте нарушенный контроль доступа, на втором ошибки конфигурации, на третьем сбои в цепочке поставок программ. Какую-то форму первых двух OWASP нашёл в 100% проверенных приложений. Контроль доступа часто проходит любую визуальную проверку: интерфейс прячет кнопку, а сервер всё равно выполнит запрос, если он придёт. Правило OWASP звучит как «по умолчанию запрещено», и применяется оно в серверном коде.

Никакой сканер не проверит эти правила за вас, потому что то, кто может видеть какой заказ или счёт, и есть ваша бизнес-логика. Это ещё один довод строить систему вокруг того, как компания работает на самом деле, и записывать роли раньше экранов. QA и тестирование затем проверяет их реальным аккаунтом каждой роли. Продукт, быстро собранный с помощью ИИ-инструментов, здесь обычно самое слабое место. Наша оценка MVP, от $3 000, говорит, что оставить, доработать или переписать, а как мы это решаем, разобрано в статье Вы собрали MVP с помощью ИИ. Оставить, доработать или переписать?

СТАРЫЙ КОД

Обновления и календари поддержки

Лучше всего цифрами описаны плагины. Patchstack насчитал в экосистеме WordPress за 2025 год 11 334 новые уязвимости, на 42% больше, чем в 2024-м: 91% в плагинах, 9% в темах и всего 6 в ядре WordPress. Взвешенная медиана времени до первого использования самых востребованных у злоумышленников уязвимостей составила 5 часов, а для 46% уязвимостей на момент раскрытия у разработчика не было исправления. В тестах Patchstack традиционная защита хостинга заблокировала 12% атак на WordPress через уже известные уязвимости. Patchstack сам продаёт защиту от этого, так что последнюю цифру стоит взвешивать с поправкой. Сам WordPress выглядит здесь хорошо; риск зависит от того, сколько плагинов на сайте и кто их ещё поддерживает.

Отсюда два практических вывода. Удалённый ненужный плагин закрывает риск, который обновление может и не закрыть, ведь почти половина уязвимостей появляется без готового исправления. OWASP советует то же: убирать неиспользуемые зависимости и следить за компонентами, которые больше никто не поддерживает. И к скорости стоит относиться честно: по данным Verizon, в 2025 году полностью исправили только 26% уязвимостей из списка CISA, куда входят уязвимости с подтверждённым использованием, а медиана выросла до 43 дней с 32 годом ранее. Наборы данных разные, поэтому разрыв между 43 днями и 5 часами это иллюстрация, а не измерение.

В заказных системах та же работа строится вокруг публичных календарей поддержки. На ноябрь 2026 года:

Даты устареют, привычка останется. Занесите их в календарь на год вперёд, проводите каждое обновление на закрытой копии и выпускайте его в час, когда клиентов меньше всего. В конце нужна настоящая тестовая заявка, а не просто открывшаяся страница. Порядок работы описан в статье Обновление старого сайта на Laravel или PHP в 2026 году. Там же есть сайт, у владельца которого не было видимых причин для беспокойства: PHP 5.6 на сервере, хостинг-аккаунт под контролем человека вне компании, служебные скрипты в открытом доступе и ошибки PHP, которые могли показываться посетителям. Контролируемый переезд решил это за два вечера.

Когда сайт отстал на несколько версий, цена зависит больше от запущенности, чем от расстояния между версиями; почему, объясняет статья Скрытый технический долг, из-за которого редизайн сайта стоит дороже плана. Такой случай начинается с аудита в рамках услуги Модернизация сайта: обновление PHP, Laravel и CMS, от $300 для небольших сайтов и от $1 000 для крупных.

ДОСТУПЫ

Пароли и забытые аккаунты

Самый наглядный публичный пример риска с паролями это кампания 2024 года против клиентов Snowflake, облачной платформы данных. Mandiant не нашёл признаков взлома самой Snowflake; уведомили около 165 организаций, которые могли пострадать. На аккаунтах не было многофакторной аутентификации, минимум у 79,7% учётные данные уже утекали раньше, а часть из них была украдена ещё в ноябре 2020 года и с тех пор не менялась.

Актуальное руководство NIST, SP 800-63B-4, ушло далеко от правил, которые многие компании всё ещё применяют. Пароль, который используется как единственный фактор, должен быть не короче 15 символов. Требования к составу и принудительная периодическая смена отменены, кроме случаев, когда есть признаки компрометации, а новые пароли нужно сверять со списками утёкших. В документе прямо сказано, что пароли не защищают от фишинга, поэтому для самых важных аккаунтов лучшим вторым шагом будет аппаратный ключ или passkey.

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

1. Регистратор домена. Кто владеет доменом, тот может направить ваш сайт и почту куда угодно.
2. Основная рабочая почта. Сюда приходят сбросы паролей от всего остального.
3. Хостинг и доступ к серверу. Отсюда видны код, база и бэкапы.
4. Репозиторий кода и деплой. Изменение здесь попадает на рабочий сайт.
5. Админка сайта, платёжные аккаунты и менеджер тегов. Менеджер тегов может поставить скрипт на любую страницу, включая оплату.

Заброшенные аккаунты дают тот же риск, только с отсрочкой: у компании могут быть сильные меры защиты и при этом действующие доступы к серверу у бывших подрядчиков, которые никто не отозвал. Ведите один список того, кто и куда может зайти и на кого оформлен каждый аккаунт. Давайте людям самую узкую роль, с которой можно работать, чтобы контент-менеджер не управлял пользователями. Уходящих сотрудников отключайте, а не удаляйте, тогда история действий останется читаемой. Раздел с заявками или данными клиентов можно закрыть отдельным вторым логином.

Пароли и API-ключи храните в файлах окружения или хранилище секретов, вне кода. Документация Laravel говорит об этом прямо: файл .env не должен попадать в систему контроля версий. Если ключ там уже оказался, правильный первый шаг описан у GitHub и подходит для любого хостинга кода: отозвать или сменить ключ и только потом думать о чистке истории. Смена подрядчика означает смену этих ключей в тот же день; об этом статья Как принять сайт или приложение от другого разработчика: что забрать в первую очередь.

ФАЙЛЫ И ЗАГРУЗКИ

Загрузки и забытые файлы

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

Простую проверку можно сделать на своём сайте, и только на нём. Запросите ваш-сайт/.env и ваш-сайт/.git/config. Нужный ответ это 403 или 404. Ответ 200 с вашей обычной страницей «не найдено» будет ложной тревогой, о таких OWASP предупреждает отдельно. Если открылся сам файл, закройте его сейчас же и считайте каждый пароль внутри украденным. Заодно убедитесь, что режим отладки на рабочем сайте выключен. Laravel предупреждает, что при включённом APP_DEBUG вы рискуете показать посетителям чувствительные значения конфигурации, а OWASP относит подробные сообщения об ошибках к частым ошибкам настройки.

Для загрузки файлов у OWASP короткий список:

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

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

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

СКРИПТЫ

Скрипты, которые писали не вы

Каждый тег на сайте работает с теми же правами, что и ваш собственный код. В отчёте Verizon 2026 года третья сторона участвует в 48% всех утечек, на 60% больше, чем годом ранее, а в рознице в 68%.

Каждый скрипт на странице оплаты может прочитать то, что вводит покупатель.

Два случая показывают, как это выглядит для владельца сайта. В феврале 2024 года новый владелец купил домен и аккаунт GitHub популярной JavaScript-библиотеки Polyfill. В июне Sansec сообщил о вредоносном коде, внедрённом более чем на 100 000 сайтов, которые её загружали. Код срабатывал только на определённых мобильных устройствах в определённые часы и пропускал администраторов, так что владелец, открывая сайт с рабочего компьютера, ничего не замечал. Раньше, в деле British Airways 2018 года, трафик перенаправлялся на поддельный сайт, были похищены платёжные данные примерно 429 612 клиентов и сотрудников, а взлом оставался незамеченным больше двух месяцев. Британский регулятор оштрафовал компанию на £20 млн и назвал многофакторную аутентификацию для сотрудников и сторонних аккаунтов среди мер, которые могли помочь.

Для всех, кто принимает карты, с 31 марта 2025 года это формальное требование. Требование 6.4.3 стандарта PCI DSS говорит, что каждый скрипт на платёжной странице должен быть разрешён, его целостность подтверждена, а все скрипты занесены в реестр с письменным обоснованием. Требование 11.6.1 добавляет механизм, который предупреждает сотрудников о несанкционированных изменениях страницы и HTTP-заголовков в том виде, в каком их получает браузер.

Многие магазины встраивают форму платёжного провайдера в iframe и считают, что их это больше не касается. PCI SSC действительно убрал оба требования из анкеты SAQ A, но добавил условие: продавец подтверждает, что его сайт не подвержен атакам через скрипты. Подтвердить это можно способами вроде тех, что описаны в 6.4.3 и 11.6.1, или письменным подтверждением от провайдера, соответствующего стандарту. Как именно это оформить, спросите у своего эквайера, поскольку сам PCI SSC выполнение стандарта не контролирует.

С картами или без, работа одна и та же: перечислить все скрипты, включая добавленные через менеджер тегов, убрать то, что никто не может объяснить, и держать платёжные страницы почти пустыми. Subresource Integrity позволяет браузеру отказаться от внешнего файла, содержимое которого больше не совпадает с хешем; это работает для фиксированных версий библиотек. Content Security Policy указывает браузеру, какие скрипты можно загружать, и начать можно с режима report-only, чтобы ничего не сломать, пока вы выясняете, что страницы используют на самом деле.

ДВА СПИСКА

Список владельца и список разработчика

Большую часть риска владелец может найти, не читая код. Задайте эти вопросы своей команде или подрядчику; по нашей оценке, на сбор ответов уйдёт примерно полдня:

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

Список разработчика превращает эти ответы в работу. Часы ниже это наша оценка для планирования по одному сайту компании на поддерживаемой или почти поддерживаемой версии. Это ориентир, а не смета, а обновление через несколько версий будет отдельным проектом.

Итого от 30 до 74 часов. Порядок важнее суммы: доступы и бэкапы идут первыми, потому что ограничивают ущерб от всего, что пока остаётся открытым.

ПЕРВЫЙ ЧАС

Первый час после взлома

Эта последовательность сохраняет вам возможности; юридической консультацией она не является. Её основа взята из руководства американской FTC для бизнеса, и логика там не зависит от страны.

1. Назначьте одного ответственного и начните письменный журнал со временем. Кто и что заметил, когда. Подключите разработчика, затем юриста, а если могли пострадать данные клиентов или карт, то и специалиста по расследованию.
2. Ничего не стирайте и пока не восстанавливайте. FTC прямо пишет «не уничтожайте доказательства» и советует отключить затронутое оборудование от сети, но не выключать машины до прихода экспертов. Попросите хостинг сохранить логи сервера, потому что логи перезаписываются.
3. Ограничьте ущерб. Переведите сайт или затронутую часть в режим обслуживания. Если страница оплаты может воровать данные карт, сначала отключите платежи.
4. Смените доступы с чистого устройства. Хостинг, база, админка, почта, платёжные и API-ключи, плюс завершите все активные сессии. Как отмечает FTC, украденные логины продолжают работать и после удаления инструментов злоумышленника.
5. Найдите точку входа, прежде чем возвращать сайт. Чистый бэкап, восстановленный поверх открытой дыры, могут заразить снова, поэтому исправление идёт вместе с восстановлением.
6. Уточните сроки с юристом. Режим зависит от того, где зарегистрирована компания. В DIFC организация обязана сообщить Комиссару по защите данных о нарушении, которое может причинить серьёзный вред, и сделать это «как только это практически возможно», для чего есть форма на сайте DIFC. У ADGM собственные правила. Федеральный закон ОАЭ № 45 от 2021 года не действует в свободных зонах со своим законом о данных, требует уведомить Data Office о нарушении, создающем риск, и уведомить затронутых людей, а сроки оставляет исполнительному регламенту, поэтому текущую редакцию проверьте с юристом. Если вы продаёте людям в ЕС, статья 33 GDPR даёт 72 часа на уведомление регулятора, где это возможно. Если затронуты карты, звоните платёжному провайдеру.

Когда сайт чист, откройте отчёт «Проблемы безопасности» в Google Search Console: взломанные страницы могут получить предупреждение в поиске и в браузерах. Исправьте все перечисленные проблемы на всех затронутых страницах, затем отправьте запрос на проверку и опишите, что сделали. По словам Google, проверка при вредоносном коде занимает несколько дней, а при взломе со спамом может занять до нескольких недель.

КТО ЭТО ДЕЛАЕТ

Кто держит это закрытым

Сделать это один раз нельзя: появляются новые уязвимости, люди уходят, маркетинг добавляет теги. Наша услуга Поддержка и обслуживание сайтов закрывает эту рутину: обновления фреймворка, PHP и пакетов, патчи безопасности, ежедневные бэкапы вне сервера с тестами восстановления, мониторинг и ежемесячный отчёт, от $1 000 в месяц, время реакции зафиксировано в вашем плане. Доступы, секреты, серверы и конвейеры релизов это работа инженеров услуги DevOps и облачная инфраструктура, от $50 до $70 в час, а проверка ролей перед крупными релизами относится к QA, от $30 в час. Если людей, которые делали сайт, уже нет, начните с аудита перед приёмом проекта, от $2 500. Все цены собраны на странице цен.

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

Доступ, который можно перечислить, можно и закрыть.

FAQ

Источники

• Verizon: 2026 Data Breach Investigations Report, executive summary
• OWASP Top 10:2025
• Patchstack: State of WordPress Security in 2026
• Mandiant, Google Cloud: UNC5537 targets Snowflake customer instances
• Sansec: Polyfill supply chain attack