Безопасность 1С-Битрикс - обзор раздела

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

Как устроено

Раздел устроен как два независимых списка: чего никогда не делать и что включить дополнительно. «Основы безопасности» - про дефекты, которых не должно быть в принципе. Это неэкранированный вывод, конкатенация пользовательского ввода в SQL, форма без CSRF-токена, отсутствующая проверка владельца ресурса. «Шифрование и защита» - про механизмы, которые включают под конкретную задачу: зашифровать поле, выдать токен, отсечь бота. Туда же - закрыть каталог и запретить встраивание в чужой фрейм. Первый список действует всегда и без исключений, второй - по мере необходимости.

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

• логика прав модуля поверх него. Итоговые права пользователя - это объединение прав всех его групп. «Шифрование и защита» показывает файловый уровень на конкретном примере: файл .access.php с массивом $PERM. Статья напоминает, что он отрабатывает раньше всего остального кода на странице. Поэтому он годится для закрытия служебных каталогов целиком, независимо от логики модулей выше.

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

Один ключ шифрования обслуживает две на первый взгляд разные вещи. Это ключ crypto_key из /bitrix/.settings.php. Он используется и в шифрованных полях ORM (CryptoField), и в защищённых куках (CryptoCookie). Для двух разных механизмов защиты данных это один и тот же секрет. В кластере он обязан быть одинаковым на всех серверах, иначе куки и поля, созданные одной нодой, не прочитает другая.

Что нужно сделать

Нужно	Смотрите
Закрыть форму и вывод данных от XSS, инъекций и CSRF	Основы безопасности
Проверить права доступа перед действием пользователя	Основы безопасности
Хранить секреты в шифре и подписывать токены	Шифрование и защита
Прикрыть форму капчей и ограничить перебор паролей	Шифрование и защита

С чего начать

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

Ревью чужого или устаревшего кода. Ищите три конкретных паттерна из «Основ безопасности». Первый - одинарные кавычки вокруг HTML-атрибута. Второй - пользовательский ввод прямо в фильтре выборки без белого списка полей. Третий - вычитающий ключ -prefilters в контроллере, который снимает проверки по умолчанию. Все три - реальные примеры из статьи, а не абстрактные советы.

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

Темы раздела

• Основы безопасности: дефекты, которых не должно быть в коде - экранирование, инъекции, CSRF, права.
• Шифрование и защита: механизмы, которые включают под конкретную задачу - шифрование, JWT, капча, файловые права, кликджекинг.

Практика раздела

• Защита сайта на практике - что закрыть в первую очередь - защита, признаки взлома, чистка.

Частые вопросы

С чего начинать - с «Основ» или сразу смотреть нужный механизм в «Шифровании и защите»?

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

Обязательно ли использовать все механизмы из «Шифрования и защиты» на каждом проекте?

Нет, они включаются под конкретную задачу, а не пакетом. Шифрование полей нужно, только если в базе действительно хранятся секреты вроде API-ключей. JWT - только если у проекта есть свои токены доступа, например для интеграции. CAPTCHA - только там, где реально досаждают боты. В отличие от «Основ безопасности», где правила обязательны для любого кода без исключений, вторая статья - это меню, из которого берут нужное, а не чек-лист, который нужно закрыть целиком.

Где физически проверяются права - в коде компонента или раньше?

На двух уровнях. Первый - файловый: `.access.php` в служебной папке проверяется в прологе, ещё до загрузки ядра платформы, поэтому годится для полного закрытия каталогов вроде директорий с приватными файлами. Второй - логика прав модуля: группы пользователей, роли, права на конкретный инфоблок или раздел. Итоговые права пользователя - это объединение прав всех групп, в которых он состоит, а не права одной «главной» группы.

Один ключ шифрования подходит для всего - и для полей, и для кук, и для JWT?

Нет. Общий `crypto_key` из настроек ядра обслуживает конкретно шифрованные поля ORM (`CryptoField`) и защищённые куки (`CryptoCookie`) - это один секрет на два механизма. Токены JWT работают на отдельном ключе, который разработчик передаёт явно при вызове `JWT::encode()`, и с `crypto_key` этот ключ не связан. Путать их не стоит: смена `crypto_key` после того, как им что-то зашифровано, делает эти данные нечитаемыми, а ключ JWT можно менять независимо.

Связанные разделы

• Ядро D7 - контроллеры и их декларативные фильтры доступа (#[Csrf], #[Authentication]) - основное место, где правила этого раздела применяются на практике.
• Инфраструктура - настройка веб-сервера и NTLM/AD-авторизация как ещё один слой защиты снаружи кода приложения.
• Модули - авторизация через внешние OAuth-провайдеры (соцсервисы) - частный случай темы прав доступа и CSRF из этого раздела.
• Интернет-магазин - оплаты и персональные данные покупателя - область, где цена ошибки в правах доступа особенно высока.