Под данным Bitrix Hub кросс-скриптинг (межсайтовый скриптинг, XSS-атаки) возглавляет топ уязвимостей проектов на «1С-Битрикс: Управление сайтом». Проблема актуальна, когда в коде интернет-проекта присутствуют скрипты, предоставляющие злоумышленнику возможность использовать вызовы переменных и выполнять вредоносные операции. Главная причина такого положения вещей – отсутствие или недостаточно надежная фильтрация параметров, передаваемых скриптам. Проще говоря, проблема появляется, когда данные, принимаемые от пользователя, выводятся в браузер без необходимой фильтрации.
Специалист по информационной безопасности компании «1С-Битрикс» М. Низамутдинов разъясняет: XSS-атака может быть использована для изменения вида HTML-страниц уязвимого ресурса в контексте браузера целевого пользователя, похищения COOKIE данных браузера целевого пользователя, с последующим внедрением в его сессию, под его учетной записью.
Стоит также отметить, что эта уязвимость не является специфической проблемой для «1С-Битрикс», а возникает ввиду некачественного пользовательского кода. И чем больше фрилансеров, студий и штатных программистов работают с сайтом, тем выше вероятность стать обладателем подобной «дыры».
Источник: https://dev.1c-bitrix.ru/community/forums/forum11/topic28846/?sphrase_id=61349572
В качестве средства защиты от подобных посягательств представитель компании-разработчика рекомендует: «Использовать htmlspecialchars. Параметры тегов с динамическими значениями ограничивать двойными кавычками. Принудительно добавлять протокол (http), где это необходимо, для значений параметров тегов, таких как href или src».
Зачем используется кросс-скриптинг
Основная цель – кража cookies пользователей с помощью встроенного скрипта для выборки необходимых данных и использованием их для последующих атак и взломов. Атака осуществляется не напрямую на пользователя, а через уязвимости веб-ресурса, на который внедрен вредоносный JavaScript. Кстати, в браузере он виден, как органичная часть сайта.
Несмотря на то, что XSS-атака напрямую не несет угрозу серверу, если к злоумышленнику попадут cookies администратора, он сможет получить доступ к административной части сайта. Уязвимость ищется, как правило, в формах связи на сайте. Чтобы понять, что она есть, достаточно передать в форму запрос вида: <script>alert("cookie: "+document.cookie)</script>
Стоит напомнить, что при базовой установке «1С-Битрикс» и готовых решений, вы не столкнетесь с подобной проблемой. Она может появиться лишь ввиду доработок и внедрения дополнительного функционала при условии, что код написан не по канонам «Битрикс» и без соблюдения правил безопасности.
Альтернативно ту же строчку скрипта можно добавить в качестве GET-параметра на страницах, генерирующие таковые. Например, в каталоге, на страницах пагинации или в фильтрах интернет-магазинов: http(s)://{ваш_домен}/catalog?p=2 (вместо цифры 2). Если на странице уязвимость есть, скрипт выполнится.
Важнейшим правилом для защиты сайта от таких уязвимостей является фильтрация получаемых и передаваемых данных по способу установки экранов для символов и преобразования специальных символов в HTML-сущности. Для php это осуществляется с применением функций htmlspecialchars(), htmlentities(), strip_tags(), например:
- $name = strip_tags($_POST['name']);
- $name = htmlentities($_POST['name'], ENT_QUOTES, "UTF-8");
- $name = htmlspecialchars($_POST['name'], ENT_QUOTES).
При работе с «Битриксом» этот список можно еще дополнить методом CDatabase::ForSql. Пример: $name = CDatabase:ForSql($_POST['name']). Важно явно указывать кодировку страниц сайта: Header("Content-Type: text/html; charset=utf-8"). Альтернативно можно запретить передавать в формах кавычки и скобки, занеся их в черный список. Но при этом могут появиться проблемы, так как будут блокироваться реальные запросы, содержащие «запрещенные» символы.
В общем, несмотря на многочисленные публикации в вебе, мы не можем назвать эту уязвимость присущей именно CMS «Битрикс» и указываем ее лишь по причине распространенности. Кроме XSS-атак, к уязвимостям сайтов не специфическим для «1С-Битрикс» относят:
- SQL-инъекции;
- внедрение в имя файла;
- выполнение системных команд;
- подбор реквизитов доступа;
- логические ошибки в коде;
- межсайтовая подделка запроса CSRF;
- фишинг;
- социальная инженерия.
Подробнее можно посмотреть в документации, мы же не будем на них останавливаться, а рассмотрим более специализированные для «Битрикс» прорехи в безопасности.
Перенаправления – click.php, rk.php и redirect.php
Уязвимость открытых перенаправлений на «1С-Битрикс» известна довольно давно. На форуме разработчиков она активно обсуждается с 2014 года.
Суть проблемы заключалась в следующем: от хостинг-провайдера приходит сообщение о том, что существенно растет нагрузка на MySQL.
Скриншот с форума разработчиков «Битрикс».
Причиной этому служило множество запросов (один пользователь отметил 30000 за 4 дня) с конструкцией вида:
/bitrix/rk.php?=goto=http…
При этом, после goto указывались, как правило, низкокачественные и мошеннические сайты.
Альтернативно проблема обнаруживается в системах аналитики, где видны внутренние и внешние ссылки именно по наличию таких URLов. Это конструкция open redirect. Open Redirect (открытое перенаправление) – это редирект, позволяющий использовать произвольный URL для конечной цели перенаправления.
Собственно, проблема открытого редиректа характерна не только для «1С-Битрикс». Конкретно же на «Битриксе» уязвимость связана с тремя системными файлами:
- click.php;
- rk.php;
- redirect.php.
Примеры ссылок:
{домен_жертва}/bitrix/click.php
?anything=here&goto={домен_цель}/
{домен_жертва}/bitrix/rk.php
?id=17&site_id=s1
&event1=banner&event2=click
&goto= {домен_цель}/
{домен_жертва}/bitrix/redirect.php
?event1=click_to_call
&event2=&event3=
&goto={домен_цель}/
Кому и зачем это нужно?
Первый вариант – получение трастовых ссылок. В 2014 году умельцы так поднимали индекс цитирования (ТИЦ) продвигаемых ресурсов.
В посте в открытом доступе почти 50 ссылок такой конструкции на трастовые домены, в том числе госорганов и банков. А в конце поста автор предлагает запросить у него бесплатно базу на 400+ доменов с выявленной уязвимостью. Кстати, оптимизатор не скрывает, что пользуется уязвимостью:
Даны подробные инструкции, как индексировать ссылки, рассылать их по твиттер-аккаунтам.
Но еще интереснее, что автор предлагает в разы увеличить запросы на сайты-жертвы:
Добавим к этому автопрогоны по разным аддурилкам и базам, вот и получаем ту злополучную нагрузку на базу, о которой писал хостер.
Думаете, что 2014 год был давно? Тогда вот более свежий пример из 2017 года:
В 2018-2019 году темы по этой проблеме на форуме «1С-Битрикс» только набирали оборотов и свидетельствовали о ее массовости.
Второй вариант – фишинг. В почтовой рассылке, в сообщениях соцсетей и мессенджерах в такие ссылки маскируются мошеннические страницы, собирающие пользовательские (персональные, платежные) данные.
Третий вариант – спам для понижения авторитета сайта. Наличие огромного количества ссылок на низкокачественные ресурсы – негативный сигнал для поисковой системы о качестве сайта-донора.
Как это возможно?
Все дело в системных файлах «1С-Битрикс», используемых CMS для сбора статистики кликов и перенаправлений по рекламным баннерам и ссылкам. Возможность использовать сайт в качестве прокладки для сомнительных редиректов заложена «из коробки».
Что делать?
Как ни печально, проблема сохраняет актуальность. Несколько тем на форуме разработчиков, к сожалению, пока не привели к ее системному решению со стороны создателей CMS. На запросы пользователей поддержка предлагает установить максимальный уровень безопасности в Проактивной защите, настроить редиректы с проверкой HTTP-заголовков.
Но, как показывает практика, ни штатная «Защита редиректов от фишинга», ни многие другие средства не приносят необходимого результата. На повторное обращение техподдержка предложила удалить системные файлы.
Несмотря на абсурдность решения, оно, кстати, работает. Но при этом администратор ресурса теряет возможность отслеживать статистику кликов по баннерам и редиректов. Файлы click.php и rk.php использует модуль «Битрикса» Реклама, баннеры (advertising). Если вы этот модуль не используете – без колебаний удаляйте его, соответственно и файлы эти удалятся.
Альтернативное решение предложили пользователи форума разработчиков. В файл .htaccess добавляются строки:
Но несмотря на то, что этот способ помог некоторым участникам, стоит отметить его неуниверсальный характер. Он работает лишь в том случае, если в функционале сайта не используются редиректы и указанные файлы.
Более специализированный вариант кода:
Но и он не учитывает наличие файла click.php.
restore.php
Проблема была выявлена при тестировании проекта на проникновение. Ее подробно описали на Хабре. Мы же кратко изложим суть. На публичном IP была установлена виртуальная машина «Битрикс», что стало понятно по набору открытых портов.
При переходе по адресу ip_addr:80 в браузере открывалась страница первичной настройки CMS «1С-Битрикс» со ссылкой «Восстановить копию». Клик по ней запускает переход к модулю restore.php и в окне появляется предложение загрузить резервную копию:
restore.php осуществляет проверку и загрузку файлов, разворачивание резервных копий проекта. А это значит, что злоумышленник может загрузить посредством модуля не бекап, а файл phpinfo.php. Проведенный анализ показал, что проверка файлов «Битрикс» не сработала и скрипт с локального компьютера загрузился в корень веб-приложения.
Чтобы повторить в лабораторных условиях, была локально развернута «1С-Битрикс: Виртуальная машина» версии 7.2. Попытка загрузить скрипт через опцию «Скачать резервную копию с дальнего сайта» не увенчалась успехом. Сработала проверка. В restore.php есть код с соответствующим условием:
Но, обойти первое условие оказалось возможным. Для тестов взяли скрипт cmd.php. В CLI системы передали символы-идентификаторов с содержимым файла cmd.php в новый файл под именем cmd_boom.php: echo -e "\x1f\x8b\n$(cat cmd.php)" > cmd_boom.php. В HEX-таблице он стал выглядеть так:
Файл был выгружен в репозиторий, и ссылка на него «скормлена» restore.php. Появился прогресс-бар загрузки и со временем – сообщение об ошибке:
Но!
Был ли удален файл?
Нет! Он остается в корне и запускается.
В форме с ошибкой нажали кнопку «Пропустить», затем – «Попробовать снова». В результате вывелась страница с кнопкой «Удалить локальную резервную копию и служебные скрипты». После клика на нее все файлы удалились.
Домашняя директория очищается от скриптов restore.php, bitrixsetup.php и файла cmd_boom.php. Сделать с сайтом ничего нельзя: резервная копия сайта не восстановлена, к установке нового не перейти. В теории скрипт cmd.php можно скрыть в поддиректорию или же переименовать в index.php.
Обращение в техподдержку «Битрикс» не дало результатов. Точнее, ответ был таков, что поиск уязвимостей в restore.php не имеет смысла, так как скрипт предусмотрен для загрузки php-файлов на сайт. С одной стороны понятно, нужно заканчивать установку и настройку. С другой – проблема не одиночна, а носит массовый характер. Быстрая поверхностная проверка выявила 600+ сайтов с опубликованными ВМ:
А если копнуть глубже? Надеемся, что этот факт заставит разработчиков задуматься над вопросом повышения безопасности на выявленном участке. А пока остается лишь быть предельно внимательным и не публиковать ВМ до того, как проект будет развернут на сервере, а также внимательно следить за всеми общедоступными страницами и ресурсами.
Бесконтрольная регистрация пользователей
Это довольно свежая проблема, выявленная в 2020 году. В январе-феврале начали мелькать сообщения владельцев сайтов и разработчиков о массовой регистрации с обходом капчи и последующей рассылкой спама при помощи уведомлений об успешной регистрации на проекте.
«В течение последней недели наблюдаются массовые регистрации ботов на сайтах под управлением СУ Битрикс. Судя по записям в журнале событий регистрация происходит по адресу /auth/?register=yes Так вот, на этих сайтах раздел /auth/ либо отсутствует, либо там нет формы регистрации. Кто-нибудь сталкивался с подобной проблемой?»
Интересно, что с ситуацией сталкивались даже на сайтах, где регистрация вообще не предусмотрена, например, на лендингах и визитках. Появлялись пользователи и на проектах, где регистрация реализована через компонент main.register либо на самописном коде на API-Битрикс, где есть и reCaptcha, и правила валидации, и набор обязательных полей.
Главной причиной проблемы выступают старые компоненты:
- system.auth.registration
- system.auth.authorize
- system.auth.forgotpasswd
- system.auth.changepasswd
На страницах они появляются со значением true константы NEED_AUTH: define("NEED_AUTH", true).
Но есть нюанс. Даже если константа не установлена компоненты благополучно отрабатывают, если подается «правильный» POST-запрос. Получается, что на любую страницу сайта, на котором даже не предусмотрена регистрация, можно подать запрос и получить успешно зарегистрированного пользователя.
Разработчик и автор блога CodeBlog Панов Алексей провел исследование, составив универсальный запрос для регистрации из Postman:
Как указывалось, запрос успешно сработал и на ресурсах без регистрации (лендинги), и на интернет-магазинах, «обойдя капчу в форме регистрации». Очевидно, что при желании не составит труда автоматизировать процесс.
Хорошая новость в том, что способ защититься от атаки есть.
- При использовании самописной регистрации нужно в настройках главного модуля на вкладке Авторизация убрать галочку напротив пункта «Позволять ли пользователям регистрироваться самостоятельно» и установить напротив «Использовать CAPTCHA при регистрации». Хотя бы на время наплыва ботов. Способ не работает, если предусмотрена регистрация по СМС.
- Совершать необходимые проверки полей нового пользователя в обработчике события OnBeforeUserAdd. Так можно не дублировать валидацию в коде, где возможна регистрация.
- Настроить указанные компоненты system.auth.* надлежащим образом.
В техподдержке «Битрикс» проблема известна, но они лишь «разводят руками», просто предлагая устанавливать капчу. Остается надеяться, что со временем уязвимость будет устранена. А пока рассчитываем только на свои силы.
Где проверить сайт на уязвимости
Мы готовы провести аудит качества кода вашего сайта или интернет-магазина. При этом выявляются не только уязвимости, но и прорехи в производительности, вероятные ошибки в работе основных инструментов сайта, проблемы со скоростью загрузки. И не забывайте: если ваш сайт по какой-то причине был выбран злоумышленниками в качестве цели, вполне возможен комплексный подход ко взлому. Делайте бекапы и следите за качеством кода и подрядчиков, с которыми вы сотрудничаете для его написания.
В качестве резюме (оптимистическое)
«1С-Битрикс» позволяет отбросить множество рисков. CMS на самом деле содержит реально работающие инструменты, которые помогут повысить уровень защиты вашего сайта от нежелательных атак. Поэтому мы рекомендуем создавать серьезные проекты именно на «Битрикс». При этом важно:
- поддерживать актуальность CMS – вовремя обновлять до последней версии;
- обеспечивать высокое качество разработки или доработок вашего сайта исполнителями.
Ведь сама по себе пустая CMS практически не несет рисков. Проблемы могут начаться при неквалифицированном вмешательстве, когда происходит программирование страниц, функционала, шаблонов.
Тема о проблемах безопасности в вебе всегда будет актуальна. И чем популярнее CMS, тем больше вариантов разнообразных атак на нее. Но не стоит постоянно думать только об этом. Достаточно соблюдать несколько простых правил, чтобы не переживать о своем сайте:
- вовремя обновлять CMS;
- доверять работу с сайтом квалифицированным специалистам;
- держать актуальные резервные копии;
- при обнаружении проблем оперативно обратиться к разработчикам для их ликвидации;
- систематически проверять безопасность ресурса (мы рекомендуем делать это раз в 2-3 месяца).
Где искать профессионалов в Битриксе, вы теперь точно знаете!