Проактивный фильтр не работает для групп пользователей битрикс

Проактивная защита: совет, как правильно настроить исключения

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

Но установив защиту, контент редакторы иногда сталкиваются с проблемой размещения некоторых материалов. Проактивная защита запрещает размещать или модифицирует JavaScript или HTML код, который теоретически может быть опасным.

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

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

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

На вкладке «Операции, которые содержит данный уровень доступа» укажите разрешение на «Обход проактивного фильтра (security_filter_bypass)»

Половина дела сделана! Теперь вы можете зайти в любую группу пользователей, которым хотите дать право на размещение JavaScript и контролируемый обход Проактивного фильтра и выбрать новую роль в настройках прав доступа группы.

Такой путь мы считаем правильным. Вы сможете работать удобно, и в тоже время не понизите уровень безопасности проекта.

Кстати, мы на всех сотрудников в компании купили Aladdin eToken PASS и авторизация на наших сайтах для сотрудников возможна только с таким вот устройством:

В Журнал вторжений на нашем сайте поступает примерно по 7500 записей за две недели.

Подробнее о Проактивной защите можно почитать у меня в блоге или на сайте в разделе Проактивная защита .

Источник

Вопрос #236

Проактивный фильтр не работает для групп пользователей

Правильный ответ на вопрос:

для которых в правах доступа к модулю «Проактивная защита» разрешена операция «Обход проактивного фильтра»

Другие вопросы теста

Возможно Вам будут интересны следующие советы для веб разработчиков

• 17 октября 2021 Компании Lion Recruitment требуется Разработчик Python + DS ML в Москве .
• 17 октября 2021 Компании Ingroup Consulting требуется PHP / JavaScript разработчик в Пензе .
• 17 октября 2021 Компании Тур Е.А. требуется Администратор интернет-магазина на shop.by + Bitrix. в Минске .
• 17 октября 2021 Компании Гущин Д. А. требуется Node.js Full Stack разработчик в Москве .
• 16 октября 2021 Middle/Senior Frontend требуется в Москве .

• 17 ноября 2017
  Пример реализации консольного скрипта с подключением ядра 1С-БитриксДавно известно, что ряд операций выносят в отдельные php файлы и запускают из консоли, так как это зачастую удобнее, быстрее, да и в принципе на эти операции не нужен браузер.
• 24 июля 2017
  MySQL ошибка: InnoDB Error Fetch of persistent statistics requested for tableПри разработке одного проекта, часто стали вылетать ошибки базы или просто бесконечная загрузка страницы. После попыток запустить сайт и перезапуска локального сервера — результат ноль.
• 19 июля 2017
  Битрикс отправка писем с вложениями без танцев с бубномОтправка писем с аттачем в bitrix довольно распространенная задача, например, отсылать пользователям договора, анкеты, выписки и другие файлы. В интернете довольно много различных способов решения задачи.
• Все советы разработчику →

• 13 июня 2018 в 17:08
  Galinaced FrancisbaxVX : По моему мнению Вы пошли ошибочным путём.
• 31 мая 2018 в 15:03
  Igorpi IgorpiNP : Номер не пройдет!
• 31 мая 2018 в 12:58
  Galinaced FrancisbaxVX : Я извиняюсь, но, по-моему, Вы допускаете ошибку. Пишите мне в PM.
• 31 мая 2018 в 08:32
  Alexeyced AlexeycedYO : Какие слова. фантастика

• 29 мая 2017
  Обновление ответов сертификации и сайта Майское обновление сайта.
• 2 ноября 2015
  Новый дизайн портала BXCert Сегодня мы выпустили новый дизайн нашего проекта. Портал стал выглядеть более современно, как нам кажется.
• 10 июня 2015
  Новый дизайн и фильтр монитора фриланс бирж Рады сообщить, что мы выпустили новый дизайн раздела монитора проектов с фриланс бирж. Новый дизайн выполнен в минималистичном стиле, все проекты теперь оформлены более компактно.
• Блог проекта →

О проекте

Проект BX Cert — портал web разработчиков. Данный ресурс будет полезен как новичкам в разработке, так и более опытным web разработчикам.

По всем вопросам Вы можете писать на почту:

Актуальные вакансии

Мы собираем и храним информацию по всем вакансия web разработчиков и программистов PHP, Python и многих других специалистов.

Компании Lion Recruitment требуется Разработчик Python + DS ML в Москве
17 октября 2021

Компании Медэк Старз Интернешнл требуется Разработчик Битрикс24 (Bitrix24) в Москве
17 октября 2021

Источник

Обнаружен способ обхода проактивного фильтра Bitrix WAF

Метод заключается в эксплуатации ошибки в регулярном выражении.

Эксперты компании High-Tech Bridge обнаружили способ обхода проактивного фильтра (Bitrix WAF), используемого в системе управления сайтами Bitrix Site Manager (Bitrix24). Метод заключается в эксплуатации ошибки в регулярном выражении.

В ходе одного из аудитов исследователи столкнулись с сайтом на базе Bitrix Site Manager с самописным кодом, содержащим множественные XSS-уязвимости, однако встроенный проактивный фильтр существенно затруднял их эксплуатацию. Уязвимый код имел примерно такую структуру:

Как видно, XSS присутствуют в трех параметрах. Bitrix WAF успешно блокировал все классические попытки эксплуатации (срабатывали правила, основанные на обработке содержимого страницы post_filter).

Обработка содержимого страницы происходит в следующей функции:

На вход этой функции попадает содержимое всех JavaScript-кодов на странице. Функция блокирует JavaScript, заменяя его строкой ) в случае, если:

JavaScript-код содержит любую входную переменную с кавычками;

JavaScript-код содержит вне строковых выражений (кроме чисел и строк длиной мене трех символов) любую входную переменную без кавычек.

Для второй проверки используется функция removeQuotedStrings:

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

Можно проэксплуатировать с помощью PoC-кода

Если добавить еще одну кавычку, метод removeQuotedStrings вернет строку с вырезанной выполняемой частью JavaScript-кода (вместо строк) и позволит обойти вторую часть фильтрации в функции isDangerBody().

не сработает, поскольку параметр P1 содержит кавычку, а значит его поиск будет осуществятся по необработанной строке (первая часть фильтрации isDangerBody).

Остаются еще два параметра для манипуляции. В один можно внедрить переводы строки и кавычки, а в другой – выполняемый JavaScript-код. Можно также исключить любой параметр из анализа, сделав его длину менее чем три символа.

В случае отсутствия кавычек из анализа проактивного фильтра параметр P2 исключается полностью. Последней строке таблицы соответствует PoC-код

С целью избежать синтаксической ошибки в JavaScript-коде в последний параметр нужно добавить еще одну кавычку. PoC-код test.php?P1=\%0A&P2=alert(/ImmuniWeb/)&P3=» будет соответствовать следующему коду HTML:

Данный JavaScript-код является корректным, а PoC-код не блокируется проактивным фильтром. Значения P1 и P3 не подвергаются анализу, поскольку их длина менее трех символов. Вследствие описанной выше ошибки в регулярном выражении значение параметра P2 целиком исключается из анализа в случае отсутствия кавычек.

Источник

Про некоторые рекомендации при ппрохождении тестов

Выявлены следующие недочеты:
1. При регистрации не используется CAPTCHA
2. Уровень безопасности административной группы не является повышенным
3. $DBDebug в значении true —

как решить такие вопросы? Пошагово?

Добавлено через 26 минут
Безопасность(4/0/9)

x 1. Используется проактивная защита. Минимальный уровень — «Стандартный» 1
2. Административные учетные записи — защищены 1
3. Группам пользователей предоставлены минимально необходимые права
4. Удалены тестовые данные
x 5. Настроены политики безопасности по работе с БД 1
x 6. Отключен вывод ошибок и предупреждений посетителям проекта 1
7. Настроен журнал системных событий
x 8. Проверена безопасность кода (статический анализ уязвимостей) 1
9. Проверка сканером безопасности

Помощь в написании контрольных, курсовых и дипломных работ здесь.

Планируется сборка среднего ПК. Необходимы некоторые рекомендации
Добрый день! Планируется переход с древнего INTEL на более-менее современный AMD, так что кроме.

Обозреватель тестов не видит тестов при открытии решения с расшаренного сетевого диска
Всем привет! Есть «решение» с несколькими проектами, пересобирается это «решение» прекрасно.

UAC — как настроить, чтоб про некоторые проги не спрашивал подтверждения при запуске?
Надоело жать, что согласен на внесение изменений, при запуске некоторых из программ. А именно.

да читал — сейчас список рекомендаций напротив тестов
1. Используется проактивная защита. Минимальный уровень — «Стандартный» — Выявлены следующие недочеты:
1. Уровень безопасности административной группы не является повышенным — хотя я в настройках поставил уровень повышенный?
2. Административные учетные записи — защищены —
В разделе «Настройки > Пользователи > Группы пользователей > Администраторы (ID группы = 1) на вкладке «Безопасность» в списке «Предопределенные настройки уровня безопасности» должно быть установлено значение «Повышенный» (или выше).

Там же на вкладке «Параметры» в разделе «Пользователи в группе» проверьте, какие учетные записи включены в группу «Администраторы». Для них необходимо включить использование одноразовых паролей.

В разделе «Настройки > Проактивная защита > Одноразовые пароли» должно быть включено использование одноразовых паролей.
В форме редактирования параметров каждой административной учетной записи: «Настройки > Пользователи > Список пользователей» на вкладке «Одноразовые пароли» должно быть настроено и включено их использование.
Также рекомендуется, при необходимости, использовать повышенный уровень безопасности (и возможно одноразовые пароли) для учетных записей других привилегированных групп, таких как администраторы магазина, администраторы каталогов и т.п.

Источник

Версия 8.0: Проактивная защита — первое знакомство (Дополнено 1)

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

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

Я буду неторопливо рассказывать, так что наберитесь терпения Итак.

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

Большинство разработчиков работает в нашей компании уже по 5-8 лет и можно сказать, что ребята очень хорошо обучены и натренированы в вопросах безопасности специалисты. Т.е. как тезис я бы сказал, что мы располагаем наиболее квалифицированными веб-разработчиками с прекрасными знаниями вопросов безопасности.

Но, несмотря на это, отдел безопасности регулярно находит потенциальные уязвимости и возвращает модули на доработку.

Мы с Юрой Тушинским, техническим директором, как-то обсуждали эту ситуацию. Почему тезис «обучение веб-разработчиков безопасности» не дает полной уверенности в качестве разработки?

Ответ довольно просто формулируется — разная психология. Разработчик думает как решить бизнес-задачу быстро, эффективно, сделать производительно, удобно для пользователя, совместимо и другие аналогичные аспекты. Хакер думает совсем в другом векторе: как сломать, как подменить данные, что сделать с плохой обработкой ошибок, как злоупотребить.

Юра рассказывал, что он сам после 3 недель работы по теме безопасности потом не может начать нормально программировать довольно долго, голова думает совсем не о разработке.

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

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

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

Еще одна проблема — на безопасность клиенты никогда не дают деньги. А если клиенты и дают деньги, то компаниям сложно найти специалистов и содержать их на нерегулярных контрактах.

Напомню статью по этой проблематике Алексея Лукацкого — Защищенный сайт

В общем, получается Security through obscurity — безопасность через незнание.

Учитывая положение вещей мы старались сделать Bitrix FrameWork максимально устойчивым и проверенным по безопасности.

API функции делались безопасными, стандартные инструменты по работе с переменными многократно проверялись и страховали разработчика от большинства типовых ошибок. Потенциально опасные действия собирались в классы и экранировали веб-разработчиков от необходимости думать о безопасности. Так работа с файлами, которая несет в себе массу угроз, собрана в отдельные классы, многократно контролируемые по безопасности. Политика безопасности групп пользователей защищала пароли и запоминанемые хэш функции от похищения. Привязки авторизованных сессии к IP, единая авторизация на всех проектах, трехуровневая система разграничения прав, CAPTCHA и масса других решений.
Все это было и есть в продукте. И я думаю, что нам удалось всеми этими действиями очень сильно поднять уровень защищенности и качество разработки приложений написанных на базе Bitrix Framework.

Но это не дает 100% защиты. Веб-разработчик теоретически может проигнорировать рекомендованные функции, взять переменную прямо из запроса, без обработки вставить в запрос к базе данных и получить одновременно и SQL Injection и эксплуатируемый XSS. И тогда все усилия оказываются напрасными, человеческий фактор сводит на нет усилия.

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

А вот хакеру не требуется долгого обучения, чтобы воспользоваться классическими и самыми массовыми уязвимостями веб-приложений, такими как XSS, SQL Injection, PHP Including. И проверить свои знания он может с легкостью на любом сайте.
Более того, есть даже инструменты для автоматизированного поиска уязвимостей на сайтах.

Я бы охарактеризовал соотношение квалифицированных веб-разработчиков к хакерам как 1:100. Опять же, не поймите это как укор. Так получается, что рядовой веб-разработчик начинает глубоко вникать в вопросы безопасности только когда впервые сталкивается с проблемами.

Безусловно, к угрозам безопасности необходимо относить не только веб-приложений, но и угрозы безопасности Информационной среды. Но это уже за пределами этого сообщения. Подробнее я писал на нашем сайте: http://www.1c-bitrix.ru/products/cms/security/threats.php

Как вариант мы долгое время рассматривали направление платных аудитов безопасности.
Наш отдел безопасности выполнял аудит безопасности по запросам крупных клиентов и партнеров. Очень интересная практика и ценнейшие данные для анализа!

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

Мощности по проверке у нас незначительные, это не основная для нас деятельность. Наращивать объем оказания услуг нет возможности.

В итоге, услуга аудит-безопасности не получила широкого тиражирования и была снята с продажи.

Мы решили изменить направление развития по теме безопасности. И стали искать решения, которые могли бы помочь всем партнерам и клиентам в равной степени.

Такое длинное вступление я сделал, чтобы вы лучше поняли, почему мы выбрали направление по разработке модуля и какие мы ставим перед собой задачи, в чем мы надеемся помогать веб-разработчикам и клиентам.

Для себя мы определили модуль «Проактивной защиты» как комплекс технических решений по обеспечению безопасности продукта и разработанных веб-приложений, включающий несколько уровней защиты от большинства известных атак на веб-приложения, существенно повышающий уровень безопасности интернет-проектов.

«Проактивная защита» является важным дополнением к стандартной политике безопасности продукта. Модуль включается во все редакции Управления сайтом кроме Старта и в Корпоративный портал.

Модуль включает в себя комплекс систем по защите веб-приложений:
* Панель безопасности с оценкой уровнями безопасности
* Проактивный фильтр (Web Application FireWall)
* Технологию одноразовых паролей (OTP)
* Защиту авторизованных сессий
* Контроль активности
* Защиту редиректов от фишинга
* Шифрование канала передачи через SSL
* Журнал вторжений
* Защиту административных разделов по IP
* Стоп-листы
* Контроль целостности
* Рекомендации по настройке
* Защиту редиректов от фишинга (пока в разработке)
* Шифрование канала передачи через SSL (пока в разработке)
* Монитор обновлений (в разработке)
* Внешний контроль инфосреды (в разработке)

Сейчас я по порядку расскажу о возможностях модуля и какие задачи мы решаем тем или иным функционалом.

Проактивная защита: панель безопасности и оценка уровня безопасности

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

Мы реализовали панель безопасности на которой все функиции модуля сгруппированы в уровни: Начальный, Стандартный, Высокий, Повышенный

Начальный уровень безопасности получают проекты на базе Bitrix Framework без установленного модуля Проактивной защиты. Это был тема большой дискуссии внутри компании, почему так называть и почему такой уровень. И все же мы решили, что так как партнеры не проверяют свои разработки на безопасность, клиенты иногда не устанавливают обновления продукта, мы будем ставить Начальный уровень безопасности.

Стандартный уровень безопасности получают проекты с включенными элементами проактивной защиты:

Проактивный фильтр (Web Application FireWall) на весь сайт без исключений, включен Контроль активности, ведется журнал вторжений. Уровень безопасности для группы Администраторы должен быть установлен в Повышенный.

Напомню, какие параметры там устанавливаются:

* Время жизни сессии (минут)
* Маска сети для привязки сессии к IP
* Максимальное количество компьютеров на которых может быть одновременно быть запомнена авторизация
* Маска сети для привязки сохраненной авторизации
* Срок хранения авторизации, запомненной на компьютере пользователя (минут)
* Срок действия контрольного слова для восстановления пароля (минут)
* Минимальная длина пароля
* Пароль должен содержать латинские символы верхнего регистра (A-Z)
* Пароль должен содержать латинские символы нижнего регистра (a-z)
* Пароль должен содержать цифры (0-9)
* Пароль должен содержать знаки пунктуации (,.<>/?;:'»[]<>\|`

!@#$%^&*()-_+=)
* Количество попыток ввода пароля до показа CAPTCHA (защита от перебора)

Все эти правила устанавливаются в настройках группы пользователей и включаются в ядро продукта.

Мы так же посчитали важным, чтобы на сайте был включен параметр «Использовать CAPTCHA при регистрации». Режим вывода ошибок (error_reporting) был установлен в Только ошибки, чтобы не раскрывать информацию о конфигурации системы.

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

Высокий уровень безопасности получают проекты выполнившие требования Стандартный плюс:
* включившие Журналирование событий главного модуля
* установившие Защиту административной части по IP
* включивших Хранение сессий в базе данных
* и Смену идентификатора сессий

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

Повышенный уровень безопасности можно будет получить включив в дополнение к Высокому уровню защиту одноразовыми пароля OTP для администраторов, Контроль целостности и еще ряд параметров (уточняются).

Начиная с версии 8.0 модуль Проактивной защиты будет по умолчанию включен в продукте. Все текущие клиенты загрузят и установят этот модуль по технологии SiteUpdate и он автоматически установит параметры соответствующие уровню безопасности Стандартный.

Теперь немного подробнее о функционале.

Проактивный фильтр (Web Application Firewall)

Проактивный фильтр (Web Application Firewall*) — обеспечивает защиту от большинства известных атак на веб-приложения. В потоке внешних запросов пользователей проактивный фильтр распознает большинство опасных угроз и блокирует вторжения на сайт.

Проактивный фильтр (Web Application Firewall) – наиболее эффективный способ защиты от возможных ошибок безопасности, допущенных при реализации интернет-проекта (XSS, SQL Injection, PHP Including и ряда других).

По данной теме рекомендую посмотреть следующие ссылки:

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

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

1 Сделать данные безопасными
2 Очистить опасные данные
3 Добавить IP-адрес атакующего в стоп-лист на ХХ минут.
4 Занести попытку вторжения в журнал

Сделать данные безопасными означает, что данные будут модифицированы. Например «select» будет заменен на «sel ect», а «

Источник