Аудит уязвимостей сайта на 1С-Битрикс: пентест, сканирование и отчёт по CVSS

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

Почему онлайн-сканера недостаточно

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

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

Что такое пентест и зачем он нужен

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

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

Какие уязвимости реально опасны для Битрикса

На проектах на 1С-Битрикс мы из раза в раз встречаем одни и те же слабые места. Первое — SQL-инъекции в самописном коде. Стандартное ядро Битрикса при правильном использовании защищено, но разработчики часто пишут прямые SQL-запросы в фильтрах каталога и обработчиках, подставляя в них параметры без фильтрации. Второе — XSS в полях, которые выводятся без экранирования: отзывы, поиск, пользовательские профили. Третье — слабая защита форм от CSRF и отсутствие проверки токенов в кастомных AJAX-обработчиках.

Отдельная и самая коварная группа — логические уязвимости доступа. В B2B-проектах с кабинетами контрагентов почти всегда есть риск IDOR: заказ, счёт или акт выдаётся по идентификатору, а проверки, что объект принадлежит текущему пользователю, нет. Сюда же относятся обход авторизации и эскалация прав, когда обычный пользователь дотягивается до административных функций. Замыкают список небезопасная загрузка файлов, ведущая к RCE, и устаревшие модули маркетплейса с публично известными CVE, для которых уже готовы эксплойты. Если ваш проект сложный и кастомный, имеет смысл совместить пентест с аудитом кода 1С-Битрикс, чтобы найти не только эксплуатируемые дыры, но и опасные паттерны в самом исходнике.

Как мы ведём аудит уязвимостей

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

Дальше идёт двухслойная проверка. Сначала автоматическое сканирование на типовые уязвимости и инвентаризация версий с проверкой на CVE. Затем ручной пентест по классам угроз: инъекции, XSS, CSRF, обход авторизации, IDOR, загрузка файлов. Каждую найденную уязвимость мы воспроизводим и оцениваем по CVSS, отсекая ложные срабатывания. На выходе — отчёт, где находки отсортированы по уровню риска, каждая описана с шагами воспроизведения и конкретным способом устранения. Мы пишем так, чтобы по отчёту мог работать и ваш разработчик, и сторонний подрядчик.

Что делать с найденными уязвимостями

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

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

Когда стоит заказывать пентест

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

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

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

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

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

«Сканер ничего не нашёл, значит, всё в порядке». Чистый отчёт сканера говорит лишь о том, что нет очевидных типовых дыр. Самые опасные уязвимости — логические, и они не находятся автоматикой по определению. Именно поэтому ручной пентест находит критичные риски там, где сканер показывал зелёный свет, и именно за этим к нам и приходят.

Почему важно подтверждать находки

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

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

Как пентест встраивается в жизненный цикл проекта

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

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

Что важно подготовить к старту

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

С чего начать

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