Доработка безопасности Битрикс: закрытие уязвимостей и проактивная защита

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

Почему «работает — значит безопасно» не работает

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

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

Какие уязвимости встречаются на Битрикс чаще всего

Вопреки расхожему мнению, чаще страдает не ядро платформы, а то, что вокруг него. Лидируют SQL-инъекции в самописных запросах и кастомных компонентах, где данные пользователя попадают в запрос к базе без экранирования. На втором месте — межсайтовый скриптинг XSS в формах и выводе пользовательского контента, через который крадутся сессии и подменяются страницы. Дальше идут CSRF — подделка запросов от имени авторизованного пользователя, обход авторизации в плохо защищённых API и кабинетах, загрузка вредоносных файлов через формы без проверки типа и содержимого.

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

Что даёт проактивная защита

Проактивный подход переворачивает логику: вместо того чтобы ждать атаку и реагировать, мы заранее ставим рубежи, которые отсекают типовые угрозы автоматически. Веб-файрвол и фильтрация запросов на входе блокируют явные попытки инъекций и подбора. Жёсткое разграничение прав по принципу минимума не даёт скомпрометированной учётке менеджера дотянуться до критичных функций. Валидация и экранирование данных закрывают инъекции там, где они возникают. Журналирование и оповещения превращают невидимую атаку в видимое событие, на которое можно среагировать до того, как она достигнет цели.

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

Как мы проводим аудит безопасности

Любая доработка безопасности начинается с аудита, потому что лечить вслепую опасно и дорого. Мы сканируем код доработок и сторонних модулей, проверяем настройки Битрикса, веб-сервера и базы данных, анализируем права на файлы и роли пользователей, тестируем формы и точки входа на типовые уязвимости. Используем штатный сканер безопасности Битрикса, инструменты анализа кода и ручную проверку самых рискованных мест. На выходе — карта уязвимостей с приоритетами по риску: что эксплуатируется прямо сейчас, что опасно, а что можно закрыть в плановом порядке.

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

Закрытие уязвимостей без поломки сайта

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

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

Права доступа, админка и формы

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

Соответствие 152-ФЗ

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

Когда хватит аудита, а когда нужна полная защита

Мы не уговариваем всех подряд на максимальный пакет. Если сайт небольшой, кастома немного и инцидентов не было, часто достаточно экспресс-аудита и закрытия найденных дыр. Полная защита с харденингом, журналированием и приведением к 152-ФЗ оправдана там, где есть оплаты, личные кабинеты, персональные данные и реальная цена простоя. На бесплатном аудите мы честно говорим, что нужно именно вам, исходя из размера сайта, объёма кастома и чувствительности данных, а не из того, что нам выгоднее продать. Если речь о новом проекте, безопасность дешевле заложить сразу — об этом стоит подумать ещё на этапе разработки на 1С-Битрикс, когда архитектура только проектируется.

Возражения, которые мы слышим чаще всего

«Нас некому взламывать, мы маленькие». Большинство атак не адресные — это автоматические сканеры, которые перебирают сайты пачками в поисках известных дыр. Им всё равно, большой вы или маленький: уязвимый модуль одинаково ломается у всех. Поэтому размер бизнеса не защищает, защищает закрытая дыра.

«У нас стоит антивирус хостинга, этого хватит». Антивирус хостинга ловит уже загруженные вредоносные файлы, то есть работает по факту проникновения. Он не закрывает саму уязвимость, через которую файл попал, и не мешает следующей атаке. Это полезный, но последний рубеж, а не замена защите на уровне приложения.

«Один раз закрыли — и забыли». Безопасность не разовая. Появляются новые уязвимости в модулях, обновляется код, меняются сотрудники и права. Поэтому после разовой доработки мы предлагаем регламент и, по желанию, регулярный мониторинг с патчами — чтобы защита не устаревала.

Гарантии и что вы получаете

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

Безопасность для интернет-магазинов и B2B-порталов

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

Корпоративные сайты на первый взгляд кажутся менее рискованными, но именно они чаще всего попадают под 152-ФЗ из-за форм обратной связи и заявок, а дефейс корпоративного сайта бьёт по репутации компании сильнее, чем по выручке. Мы выстраиваем защиту с учётом типа проекта: для магазина важнее непрерывность и сохранность платёжных данных, для портала — изоляция данных контрагентов, для корпоративного сайта — защита форм и соответствие закону. Универсального шаблона нет, и мы не натягиваем один набор мер на все проекты.

Как мы взаимодействуем в процессе работы

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

Мы также не привязываем заказчика к себе. По итогам работ вы получаете полный отчёт и регламент, по которым развивать защиту дальше сможет любая команда. Если же безопасность нужна на постоянной основе, мы предлагаем вынести мониторинг, патчи и периодические проверки в регулярное сопровождение — но это ваш выбор, а не условие. Цель доработки безопасности в том, чтобы сайт стал устойчивым и управляемым, а не в том, чтобы сделать вас зависимыми от подрядчика.

С чего начать

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