Безопасность магазина на Битрикс: OWASP на практике

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

Ниже — практический разбор четырёх самых опасных для магазина классов уязвимостей из OWASP Top 10: как они выглядят в коде на 1С-Битрикс, чем именно грозят данным заказов и как их закрыть штатными средствами платформы. Это выжимка из наших проектов по аудиту и защите интернет-магазинов на 1С-Битрикс — с конкретным API, а не общими словами про «важность безопасности».

Почему магазин на Битрикс — мишень для атак

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

Важно понимать, что атакуют не «Битрикс вообще», а конкретную установку. И слабым звеном почти всегда оказывается то, что добавили поверх ядра: сторонний модуль из маркетплейса, скачанный «бесплатный» шаблон с закладкой, наспех написанный обработчик формы обратной связи, кастомная выгрузка заказов. Ядро Битрикса проходит аудит вендора, а доработки — нет, если только вы сами не заложили аудит в процесс разработки.

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

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

OWASP Top 10 применительно к 1С-Битрикс

OWASP Top 10 — это признанный в индустрии список самых критичных рисков веб-приложений, который поддерживает международное сообщество Open Web Application Security Project. Он не привязан к конкретной платформе, но отлично ложится на реалии интернет-магазина. Разберём, как основные пункты списка проявляются в проекте на 1С-Битрикс.

• Нарушение контроля доступа (Broken Access Control). Сюда относится IDOR — доступ к чужим заказам и документам по прямой ссылке. Самая частая и самая недооценённая проблема магазинов.
• Инъекции (Injection). SQL-инъекции в кастомных запросах к базе, а также внедрение команд. Возникают там, где ввод пользователя попадает в запрос без обработки.
• Межсайтовый скриптинг (XSS). Внедрение чужого JavaScript через поля форм, отзывы, параметры URL. Опасен кражей сессий и данных, подменой страницы оформления.
• Подделка межсайтовых запросов (CSRF). Принуждение авторизованного пользователя выполнить действие без его ведома — сменить пароль, оформить или отменить заказ.
• Небезопасная конфигурация (Security Misconfiguration). Открытая отладка, дефолтные пароли, доступные служебные адреса, отключённый проактивный фильтр.
• Уязвимые компоненты (Vulnerable Components). Устаревшие модули маркетплейса и библиотеки с известными дырами.

В этой статье мы подробно фокусируемся на четырёх классах, которые прямее всего угрожают данным заказов: XSS, SQLi, CSRF и IDOR. Остальные пункты — конфигурацию, компоненты, обновления — мы затрагиваем в разделе про реализацию и в смежных материалах. В частности, про безопасное обновление ядра и модулей есть отдельный разбор: обновление 1С-Битрикс без простоя магазина.

Модель угроз: где живут данные заказов

Прежде чем закрывать уязвимости, полезно понять, что именно мы защищаем и откуда к этому есть доступ. Данные заказов в 1С-Битрикс живут не в одном месте, и у каждого хранилища свой периметр.

• Таблицы модуля продаж. Заказы, свойства заказов, привязка к покупателю, статусы, платежи и доставки хранятся в таблицах модуля sale. Доступ к ним идёт через API (объекты \Bitrix\Sale\Order) и напрямую через базу.
• Профили покупателей. ФИО, телефоны, адреса лежат в свойствах заказа и в профилях пользователей (модуль main, таблица пользователей и их свойств).
• Личный кабинет. Страницы истории заказов, повторного заказа, деталей — типичное место для IDOR, если проверка владельца сделана небрежно.
• Интеграции. Обмен с 1С, выгрузки в CRM, вебхуки платёжных систем — каналы, по которым данные заказов покидают магазин. Их защита разбирается отдельно в материале про безопасность REST и вебхуков в 1С-Битрикс.
• Резервные копии и логи. Бэкапы базы и файлы логов часто содержат те же персональные данные, но защищены хуже самого сайта.

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

XSS: межсайтовый скриптинг в кастомном коде

XSS (Cross-Site Scripting) — это внедрение чужого JavaScript-кода в страницу магазина. Возникает, когда пользовательский ввод выводится на страницу без экранирования. Классические места в магазине: отзывы о товаре, вопросы к товару, поле поиска (когда запрос отображается в заголовке «Вы искали…»), поля формы заказа, которые потом видит менеджер в админке, любые GET-параметры, попадающие в HTML.

Опасность XSS для магазина не в «всплывающем окошке alert», как в учебных примерах, а в тихой краже данных. Внедрённый скрипт может увести сессионные куки авторизованного покупателя или администратора, подменить реквизиты на странице оплаты, перехватить данные банковской карты (веб-скиммер), отправить содержимое формы на чужой сервер. Особенно опасен хранимый (stored) XSS: вредоносный код один раз сохраняется в базу — например, в отзыв — и срабатывает у каждого, кто открывает страницу, включая менеджера в админке.

Как закрыть. Единственное надёжное правило — экранировать любой вывод пользовательских данных в HTML. В 1С-Битрикс для этого есть штатные средства, и использовать нужно именно их, а не самописные замены:

• htmlspecialcharsbx($value) — «битриксовый» аналог htmlspecialchars, экранирует спецсимволы HTML. Оборачивайте им любой вывод переменной в шаблоне.
• \Bitrix\Main\Text\HtmlFilter::encode($value) — то же самое в стиле D7, удобно в новом коде.
• Для полей, где допустим ограниченный HTML (форматированные отзывы), — санитайзер \Bitrix\Main\Text\HtmlFilter с белым списком тегов, а не «разрешить всё».
• Для вставки данных в JavaScript-контекст — CUtil::JSEscape($value) или \Bitrix\Main\Web\Json::encode(), а не прямая конкатенация в скрипт.

Главный принцип — экранировать на выводе, а не на вводе. Данные хранятся в базе как есть, а обрабатываются в момент отображения в зависимости от контекста (HTML-тело, атрибут, JavaScript, URL). Один и тот же текст в разных контекстах экранируется по-разному, поэтому попытка «почистить» ввод один раз при сохранении почти всегда оставляет дыру.

SQL-инъекции: безопасная работа с базой

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

В 1С-Битрикс сырой SQL нужен редко, и это хорошая новость. У платформы есть слой ORM (D7), который сам параметризует запросы и экранирует значения. Правильная иерархия подходов выглядит так:

1. Используйте ORM и query-билдер. Выборки через \Bitrix\Main\Entity и getList() с фильтром-массивом безопасны по умолчанию: значения фильтра экранируются автоматически. Это основной способ работы с данными в современном коде.
2. Для заказов — высокоуровневое API продаж. Работайте с заказами через \Bitrix\Sale\Order, а не прямыми запросами к таблицам. API сам следит за целостностью и правами.
3. Если сырой запрос неизбежен — экранируйте. Пропускайте каждое значение через SqlHelper: $connection->getSqlHelper()->forSql($value) для строк и приведение типов ((int)$id) для чисел.
4. Никогда не конкатенируйте ввод напрямую. Строка вида "WHERE ID = " . $_GET['id'] — прямая уязвимость, даже если «id всегда число».

Отдельная ловушка — фильтр в getList(). ORM экранирует значения, но имена полей и операторы вы задаёте сами. Если вы подставляете имя поля для сортировки или фильтрации из пользовательского ввода без белого списка, это тоже вектор инъекции. Правило: любое имя колонки, поле сортировки или направление (ASC/DESC), пришедшее от пользователя, проверяйте по заранее заданному списку допустимых значений.

CSRF: подделка запросов и защита форм

CSRF (Cross-Site Request Forgery) — подделка межсайтовых запросов. Суть атаки: злоумышленник заставляет браузер авторизованного пользователя незаметно отправить запрос на ваш сайт. Пользователь заходит на сторонний сайт (или открывает письмо), там спрятана форма или картинка, которая шлёт запрос на ваш магазин. Браузер автоматически прикладывает куки авторизации — и сервер выполняет действие от имени жертвы: меняет пароль, оформляет заказ, отменяет заказ, привязывает чужую карту.

Защита строится на том, что сторонний сайт не знает секретного токена текущей сессии. В 1С-Битрикс этот механизм встроен и называется «защита от CSRF через bitrix_sessid». Работает он так:

1. В форму добавляется токен. Функция bitrix_sessid_post() вставляет скрытое поле с сессионным идентификатором. Для ссылок и GET-запросов используется bitrix_sessid_get().
2. На сервере токен проверяется. До выполнения любого изменяющего действия вызывается check_bitrix_sessid(). Если токен не совпадает или отсутствует — запрос отклоняется.
3. Действия идут методом POST. Всё, что меняет состояние (оформление, отмена, смена профиля, добавление в избранное с побочными эффектами), выполняется через POST, а не GET. GET-ссылки не должны менять данные.

Многие штатные компоненты Битрикса уже используют этот механизм. Но как только вы пишете свою форму или AJAX-контроллер, ответственность за проверку токена ложится на вас. Типичная ошибка — сделать красивый AJAX-обработчик «отменить заказ», который принимает ID заказа и не проверяет ни токен, ни права. Это открывает сразу и CSRF, и IDOR.

В новых AJAX-контроллерах на базе \Bitrix\Main\Engine\Controller проверка сессионного токена (sessid) выполняется автоматически для действий, требующих защиты, — это ещё один довод использовать штатный слой контроллеров вместо самописных точек входа.

IDOR: небезопасные ссылки на объекты

IDOR (Insecure Direct Object Reference) — небезопасная прямая ссылка на объект. Это самая частая и самая болезненная для магазина уязвимость. Механика простая: страница детали заказа доступна по адресу вида /personal/orders/?ID=10456. Пользователь смотрит свой заказ, потом из любопытства меняет ID в адресе на 10457 — и видит чужой заказ: ФИО, телефон, адрес доставки, состав покупки. Сервер отдал данные, потому что не проверил, что заказ 10457 принадлежит именно этому пользователю.

IDOR возникает везде, где объект идентифицируется предсказуемым значением (последовательный ID) и где проверка прав сделана «на глаз» или вынесена только на фронтенд. Особенно часто это встречается в самописных личных кабинетах, AJAX-обработчиках «повторить заказ», «скачать счёт», «посмотреть накладную» и в любых выгрузках документов по ссылке.

Как закрыть. Единственная надёжная защита — проверка владельца объекта на сервере при каждом обращении. Не «спрятать» ссылку, не сделать ID «сложным», а именно проверить право доступа:

• Сверяйте владельца. Прежде чем отдать заказ, убедитесь, что его USER_ID совпадает с $USER->GetID() текущего авторизованного пользователя.
• Проверяйте авторизацию. Любая страница с персональными данными должна начинаться с проверки $USER->IsAuthorized() — анонимный доступ к деталям заказа недопустим.
• Используйте API продаж. Высокоуровневые методы работы с заказами учитывают контекст пользователя, но и их результат нужно сверять с владельцем — API вернёт заказ по ID, если вы явно его запросили.
• Не доверяйте фронтенду. Скрытие кнопки или проверка в JavaScript ничего не защищает: запрос можно отправить напрямую. Решение принимает только сервер.
• Логируйте доступ к чувствительным объектам. Аномальный перебор ID проще заметить, если обращения к деталям заказов журналируются.

Дополнительная мера — использовать непоследовательные, непредсказуемые идентификаторы (например, случайные токены доступа к документу вместо голого ID). Но это именно дополнение: без серверной проверки прав даже случайный токен рано или поздно утечёт через историю браузера, логи или реферер. Проверка владельца — обязательна, обфускация ID — приятное дополнение.

Уязвимости и защита: сводная таблица

Сведём четыре основных класса угроз в одну таблицу — это удобно держать перед глазами при код-ревью и при постановке задач на доработку.

Защита данных заказов и персональных данных

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

• Принцип наименьших привилегий. Менеджеру нужен доступ к заказам своего склада, а не ко всей базе. Настраивайте роли и права модуля так, чтобы каждый видел минимум необходимого.
• Только HTTPS. Весь трафик магазина — по защищённому соединению, с редиректом с HTTP и корректным HSTS. Данные заказа не должны ходить в открытом виде.
• Чистые логи и уведомления. Не пишите полные персональные данные и тем более данные карт в логи, письма и служебные уведомления. Логи — тоже объект утечки.
• Защита резервных копий. Бэкапы базы содержат те же ПДн. Храните их в защищённом месте с ограниченным доступом и по возможности в зашифрованном виде.
• Журналирование доступа. Модуль безопасности умеет журналировать действия в админке. Это и требование регламентов, и способ заметить аномалию — например, массовую выгрузку заказов ночью.
• Согласие и хранение. Собирайте согласие на обработку ПДн, не храните данные дольше необходимого, обеспечьте механизм удаления по запросу.

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

Загрузка файлов и небезопасная десериализация

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

Загрузка файлов. Формы «прикрепить фото к отзыву», «загрузить документ», аватары в личном кабинете — потенциальная возможность залить на сервер исполняемый скрипт. Если проверять только расширение или доверять MIME-типу из запроса, злоумышленник загрузит PHP-файл под видом картинки и получит удалённое выполнение кода. Правила защиты: проверяйте реальный тип файла, а не заголовок; храните загрузки вне корня сайта или в каталоге с запретом на исполнение; переименовывайте файлы, не сохраняя оригинальное имя; ограничивайте размер и разрешённые типы белым списком. В Битриксе для работы с файлами используйте штатный CFile, который учитывает эти нюансы.

Небезопасная десериализация. Если код принимает от пользователя сериализованные данные и разворачивает их через unserialize(), это открывает путь к внедрению объектов и выполнению кода. Не десериализуйте недоверенный ввод. Для обмена данными используйте JSON (\Bitrix\Main\Web\Json), а не PHP-сериализацию. Это же касается вебхуков и интеграций — их полезную нагрузку тоже нельзя разворачивать вслепую.

• Проверяйте фактический тип загружаемого файла, а не расширение и не присланный MIME.
• Храните пользовательские загрузки в каталоге без права на исполнение скриптов.
• Не используйте unserialize() на данных, пришедших от пользователя или из внешнего канала.
• Для сериализации данных предпочитайте JSON штатными средствами платформы.

Реализация в 1С-Битрикс: модуль и API

У платформы есть выделенный модуль «Проактивная защита» (модуль security), который закрывает часть рисков на уровне конфигурации, не требуя правки кода. Его настройки живут в разделе «Настройки → Проактивная защита» админки. Ключевые инструменты, которые стоит включить и настроить на боевом магазине:

• Проактивный фильтр (WAF). Отсекает типовые вредоносные шаблоны во входящих параметрах. Включается для всех страниц; исключения задаются точечно и осознанно.
• Защита сессий. Привязка сессии к параметрам клиента и хранение сессий в защищённом хранилище затрудняют угон сессии.
• Контроль целостности. Периодическая проверка, что файлы ядра не изменены — способ заметить внедрённую закладку.
• Одноразовые пароли (OTP) и двухфакторная авторизация. Для администраторов и менеджеров — обязательный рубеж против кражи пароля.
• Журнал вторжений и стоп-лист. Логирование подозрительной активности и блокировка адресов-нарушителей.
• Уровень безопасности. Модуль предлагает преднастроенные уровни (стандартный, высокий, повышенный) — начните со стандартного и повышайте по мере готовности.

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

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

Как проверить магазин на уязвимости

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

1. Инвентаризация кастомного кода. Соберите список всех доработок: свои компоненты, шаблоны, обработчики событий, AJAX-контроллеры, кастомные страницы, сторонние модули. Именно они — основная зона риска.
2. Поиск сырых запросов и вывода. Пройдитесь по коду в поисках прямой конкатенации в SQL, вывода переменных без экранирования и приёма параметров без обработки. Это места будущих XSS и SQLi.
3. Проверка форм на CSRF. Убедитесь, что все изменяющие данные формы и AJAX-действия проверяют сессионный токен и работают через POST.
4. Тест на IDOR. Авторизуйтесь под тестовым пользователем и попробуйте открыть чужой заказ, документ, профиль, подменяя ID в адресе. Сервер должен возвращать отказ.
5. Проверка конфигурации. Отключена отладка на бое, закрыты служебные адреса, включён проактивный фильтр, стоят актуальные обновления, у администраторов — двухфакторная авторизация.
6. Ревизия прав и интеграций. Проверьте права ролей, токены REST и вебхуков, актуальность паролей интеграций. Лишние доступы отзовите.

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

Частые ошибки разработчиков

• Полагаются только на проактивный фильтр и не экранируют вывод в шаблонах — фильтр не знает контекста и пропускает нестандартный XSS.
• Собирают SQL-запрос конкатенацией с параметром из URL «потому что это всегда число» — классическая SQL-инъекция.
• Пишут AJAX-контроллер отмены заказа без проверки токена сессии — открывают CSRF в один запрос.
• Проверяют права доступа только на фронтенде (прячут кнопку), а сервер отдаёт данные любому — прямой IDOR.
• Не сверяют владельца заказа с текущим пользователем — по подменённому ID утекают чужие персональные данные.
• Пишут полные персональные данные и данные карт в логи и служебные письма — превращают лог в объект утечки.
• Доверяют расширению и MIME-типу при загрузке файлов — пропускают исполняемый скрипт под видом картинки.
• Держат устаревшие сторонние модули маркетплейса с известными уязвимостями и откладывают обновления.
• Оставляют включённую отладку и открытые служебные адреса на боевом сервере — раскрывают структуру и ошибки.

Чек-лист безопасности

Сведём всё в практический список, по которому удобно принимать готовность магазина к запуску и проверять его периодически.

1. Вывод экранируется. Все пользовательские данные выводятся через htmlspecialcharsbx / HtmlFilter::encode с учётом контекста (HTML, атрибут, JS).
2. Запросы параметризованы. Работа с данными идёт через ORM и API продаж; сырых запросов с конкатенацией ввода нет.
3. Формы защищены от CSRF. Изменяющие действия работают через POST и проверяют check_bitrix_sessid().
4. Контроль доступа на сервере. Каждый доступ к заказу, документу, профилю сверяет владельца и авторизацию; IDOR закрыт.
5. Проактивная защита включена. WAF, защита сессий, контроль целостности активны; уровень безопасности — не ниже стандартного.
6. Двухфакторная авторизация. У всех администраторов и менеджеров с доступом к заказам включён второй фактор.
7. Файлы и сериализация под контролем. Загрузки проверяются по реальному типу и хранятся без права исполнения; недоверенный ввод не десериализуется.
8. Данные заказов защищены. HTTPS везде, минимум прав по ролям, чистые логи, защищённые бэкапы, журналирование доступа.
9. Обновления актуальны. Ядро и модули обновлены, сторонние компоненты проверены; обновления ставятся по регламенту.
10. Аудит проведён. Кастомный код проверен на XSS, SQLi, CSRF, IDOR; тест на подмену ID пройден.

Вывод

Безопасность магазина на 1С-Битрикс держится на двух опорах: включённой проактивной защите платформы и дисциплине разработки. Ядро закрывает базовые риски, но реальные бреши почти всегда живут в кастомном коде — там, где пользовательский ввод попадает в HTML, в SQL или в действие без проверки токена и прав. Закройте четыре ключевых класса — XSS, SQLi, CSRF, IDOR — экранированием вывода, параметризацией запросов, сессионным токеном и серверной проверкой владельца, защитите данные заказов по принципу минимальных привилегий — и магазин перестанет быть лёгкой мишенью. Безопасность стоит закладывать сразу, а не после первого инцидента.