Непонятные посещения с редиректом.
Поздравляю. Сайт где-то попал в базы спамеров и они (скорее всего) теперь размещают ссылки на свои *** помойки через него. Устраивают с редиректом всякие неприличные вещи и все такое.
Я как-то нашел гору таких ссылок во входящих ссылках в Яндекс Вебмастере. Где-то от 3 до 15 тысяч всего. Вам и правда может прилететь за спам. Если не за спам ссылками, то тот же Яндекс банил за обман пользователей.
Делать. Закрыть от индексации, закрыть от роботов через куки и реферрер. Или вообще снести редирект. Можно еще белые списки использовать (хороший вариант) или черные. Но в черных скорее удастся только отсеять всякие популярные «взрослые» слова и популярные спамерские домены вроде //sites.google. и всех сокращателей ссылок.
Ссылки с get — параметром типа: *?goto= старая болезнь Битрикса, причем не единственная. Не ужели еще не вылечили? Или у Вас древняя версия Bitrix?
Несколько лет назад обнаружил в Вебмастере Яндекс огромное количество ссылок с *?goto= ведущих с сайта на Битрикс на порно ресурсы. Жесть.
Ссылки с get — параметром типа: *?goto= старая болезнь Битрикса, причем не единственная. Не ужели еще не вылечили? Или у Вас древняя версия Bitrix?
Несколько лет назад обнаружил в Вебмастере Яндекс огромное количество ссылок с *?goto= ведущих с сайта на Битрикс на порно ресурсы. Жесть.
На форуме битрикса вопрос левых get параметров уже несколько лет обсуждается — разработчики не реагируют.
Мне непонятно зачем это злодеям нужно.
ссылки на мою страницу с редиректом идут тоже со страниц с редиректом,
типа:
1. Почему сразу не поставить ссылку на свой сайт?
2. Я всегда считал, что ссылки с редиректом не учитываются поисковиками, зачем это вообще делается?
Топ-4 актуальных уязвимости 1С-Битрикс
Хотели написать статью об инструментах безопасности «1С-Битрикс», но постепенно «зарылись» в проблемах с этой самой безопасностью. И как оказалось, тема эта весьма актуальная. Несмотря на общепризнанный высокий уровень защищенности «Битрикс» и сегодня находятся «прорехи», которые могут причинить серьезные неприятности.
Поэтому предлагаем подробнее остановиться именно на постановке проблемы. Тем более, что именно наличие уязвимостей, как нельзя лучше говорит о необходимости высокой защиты вашего eCommerce-ресурса. А к анализу методов достижения высокого уровня безопасности разработчиками «1С-Битрикс» вернемся позже.
Содержание:
XSS-атака
Под данным Bitrix Hub кросс-скриптинг (межсайтовый скриптинг, XSS-атаки) возглавляет топ уязвимостей проектов на «1С-Битрикс: Управление сайтом». Проблема актуальна, когда в коде интернет-проекта присутствуют скрипты, предоставляющие злоумышленнику возможность использовать вызовы переменных и выполнять вредоносные операции. Главная причина такого положения вещей – отсутствие или недостаточно надежная фильтрация параметров, передаваемых скриптам. Проще говоря, проблема появляется, когда данные, принимаемые от пользователя, выводятся в браузер без необходимой фильтрации.
Специалист по информационной безопасности компании «1С-Битрикс» М. Низамутдинов разъясняет: XSS-атака может быть использована для изменения вида HTML-страниц уязвимого ресурса в контексте браузера целевого пользователя, похищения COOKIE данных браузера целевого пользователя, с последующим внедрением в его сессию, под его учетной записью.
Стоит также отметить, что эта уязвимость не является специфической проблемой для «1С-Битрикс», а возникает ввиду некачественного пользовательского кода. И чем больше фрилансеров, студий и штатных программистов работают с сайтом, тем выше вероятность стать обладателем подобной «дыры».
В качестве средства защиты от подобных посягательств представитель компании-разработчика рекомендует: «Использовать htmlspecialchars. Параметры тегов с динамическими значениями ограничивать двойными кавычками. Принудительно добавлять протокол (http), где это необходимо, для значений параметров тегов, таких как href или src».
Зачем используется кросс-скриптинг
Основная цель – кража cookies пользователей с помощью встроенного скрипта для выборки необходимых данных и использованием их для последующих атак и взломов. Атака осуществляется не напрямую на пользователя, а через уязвимости веб-ресурса, на который внедрен вредоносный JavaScript. Кстати, в браузере он виден, как органичная часть сайта.
Несмотря на то, что XSS-атака напрямую не несет угрозу серверу, если к злоумышленнику попадут cookies администратора, он сможет получить доступ к административной части сайта.
Уязвимость ищется, как правило, в формах связи на сайте. Чтобы понять, что она есть, достаточно передать в форму запрос вида:
Стоит напомнить, что при базовой установке «1С-Битрикс» и готовых решений, вы не столкнетесь с подобной проблемой. Она может появиться лишь ввиду доработок и внедрения дополнительного функционала при условии, что код написан не по канонам «Битрикс» и без соблюдения правил безопасности.
Альтернативно ту же строчку скрипта можно добавить в качестве GET-параметра на страницах, генерирующие таковые. Например, в каталоге, на страницах пагинации или в фильтрах интернет-магазинов.
http(s)://<ваш_домен>/catalog?p=2 (вместо цифры 2).
Если на странице уязвимость есть, скрипт выполнится.
Важнейшим правилом для защиты сайта от таких уязвимостей является фильтрация получаемых и передаваемых данных по способу установки экранов для символов и преобразования специальных символов в HTML-сущности. Для php это осуществляется с применением функций htmlspecialchars(), htmlentities(), strip_tags(), например:
$name = htmlentities($_POST[‘name’], ENT_QUOTES, «UTF-8»);
$name = htmlspecialchars($_POST[‘name’], ENT_QUOTES).
При работе с «Битриксом» этот список можно еще дополнить методом CDatabase::ForSql. Пример:
Важно явно указывать кодировку страниц сайта:
Header(«Content-Type: text/html; charset=utf-8»);
Альтернативно можно запретить передавать в формах кавычки и скобки, занеся их в черный список. Но при этом могут появиться проблемы, так как будут блокироваться реальные запросы, содержащие «запрещенные» символы.
В общем, несмотря на многочисленные публикации в вебе, мы не можем назвать эту уязвимость присущей именно CMS «Битрикс» и указываем ее лишь по причине распространенности.
Кроме XSS-атак, к уязвимостям сайтов не специфическим для «1С-Битрикс» относят:
- SQL-инъекции;
- внедрение в имя файла;
- выполнение системных команд;
- подбор реквизитов доступа;
- логические ошибки в коде;
- межсайтовая подделка запроса CSRF;
- фишинг;
- социальная инженерия.
Подробнее можно посмотреть в документации, мы же не будем на них останавливаться, а рассмотрим более специализированные для «Битрикс» прорехи в безопасности.
Перенаправления – click.php, rk.php и redirect.php
Уязвимость открытых перенаправлений на «1С-Битрикс» известна довольно давно. На форуме разработчиков она активно обсуждается с 2014 года.
Суть проблемы заключалась в следующем:
От хостинг-провайдера приходит сообщение о том, что существенно растет нагрузка на MySQL.
Скриншот с форума разработчиков «Битрикс».
Причиной этому служило множество запросов (один пользователь отметил 30000 за 4 дня) с конструкцией вида:
При этом, после goto указывались, как правило, низкокачественные и мошеннические сайты.
Альтернативно проблема обнаруживается в системах аналитики, где видны внутренние и внешние ссылки именно по наличию таких URLов.
Это конструкция open redirect.
Собственно, проблема открытого редиректа характерна не только для «1С-Битрикс». Конкретно же на «Битриксе» уязвимость связана с тремя системными файлами:
- click.php;
- rk.php;
- redirect.php.
Кому и зачем это нужно?
Первый вариант – получение трастовых ссылок. В 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 и в окне появляется предложение загрузить резервную копию:
Ситуация объясняется скорее всего человеческим фактором: вероятно, что администратор не завершил процедуру настройки вебсайта и Виртуальной машины VMBitrix. Но несмотря на то, что проблема связана с отсутствием контроля или ошибкой специалиста, она может стать причиной взлома.
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:
Но есть нюанс. Даже если константа не установлена компоненты благополучно отрабатывают, если подается «правильный» POST-запрос. Получается, что на любую страницу сайта, на котором даже не предусмотрена регистрация, можно подать запрос и получить успешно зарегистрированного пользователя.
Разработчик и автор блога CodeBlog Панов Алексей провел исследование, составив универсальный запрос для регистрации из Postman:
Как указывалось, запрос успешно сработал и на ресурсах без регистрации (лендинги), и на интернет-магазинах, «обойдя капчу в форме регистрации».
Очевидно, что при желании не составит труда автоматизировать процесс.
Хорошая новость в том, что способ защититься от атаки есть.
-
При использовании самописной регистрации нужно в настройках главного модуля на вкладке Авторизация убрать галочку напротив пункта «Позволять ли пользователям регистрироваться самостоятельно» и установить напротив «Использовать CAPTCHA при регистрации». Хотя бы на время наплыва ботов. Способ не работает, если предусмотрена регистрация по СМС.
Совершать необходимые проверки полей нового пользователя в обработчике события OnBeforeUserAdd. Так можно не дублировать валидацию в коде, где возможна регистрация.
Настроить указанные компоненты system.auth.* надлежащим образом.
В техподдержке «Битрикс» проблема известна, но они лишь «разводят руками», просто предлагая устанавливать капчу. Остается надеяться, что со временем уязвимость будет устранена. А пока рассчитываем только на собственные силы.
Где проверить сайт на уязвимости
Мы готовы провести аудит качества кода вашего сайта или интернет-магазина. При этом выявляются не только уязвимости, но и прорехи в производительности, вероятные ошибки в работе основных инструментов сайта, проблемы со скоростью загрузки.
И не забывайте: если ваш сайт по какой-то причине был выбран злоумышленниками в качестве цели, вполне возможен комплексный подход ко взлому. Делайте бекапы и следите за качеством кода и подрядчиков, с которыми вы сотрудничаете для его написания.
В качестве резюме (оптимистическое)
«1С-Битрикс» позволяет отбросить множество рисков. CMS на самом деле содержит реально работающие инструменты, которые помогу повысить уровень защиты вашего сайта от нежелательных атак. Поэтому мы рекомендуем создавать серьезные проекты именно на «Битрикс».
При этом по-настоящему важно:
поддерживать актуальность CMS – вовремя обновлять до последней версии;
обеспечивать высокое качество разработки или доработок вашего сайта исполнителями.
Ведь сама по себе пустая CMS практически не несет рисков. Проблемы могут начаться при неквалифицированном вмешательстве, когда происходит программирование страниц, функционала, шаблонов.
Тема о проблемах безопасности в вебе всегда будет актуальна. И чем популярнее CMS, тем больше вариантов разнообразных атак на нее. Но не стоит постоянно думать только об этом. Достаточно соблюдать несколько простых правил, чтобы не переживать о своем сайте:
На сайте для перехода на внешние ссылки используется redirect: сайт/redirect?url=сторонний сайт. Что делать?
Если у вас битрикс, делайте следующие действия:
1. Закрывайте от индексации.
Есть 3 файла, через которые возможен такой редирект:
/bitrix/redirect.php
/bitrix/rk.php
/bitrix/click.php
Ну либо просто /bitrix/
2. В разделе «Настройки > Проактивная защита > Защита редиректов»
Во-первых включите ее, если она выключена.
Во-вторых сделайте как на скрине:
https://i.imgur.com/wwPj1C5.png
И внизу желательно перенаправьте любой редирект на 404 страницу.
На меня был спам такими ссылками, довольно серьёзный, в день доходит на много тысяч ссылок, ничего страшного не будет пока такое не попадёт в индекс. Разумеется при закрытой индексации и переходе на 404 никакой вес передаваться на другие спам-сайты не будет.
Битрикс и уязвимость через rk.php
В некоторых случаях можно обнаружить высокую нагрузку на сайт из-за огромного числа заходов на сайт по ссылкам, приводящим к редиректам на внешний домен.
Иногда компании, специализирующиеся на защите и безопасности в интернете, присылают жалобы, на подобные ссылки на ваш сайт, ведущие на сайты с троянами и порнографией.
Ссылки имеют вид
- <ваш_домен>/bitrix/click.php. &goto=<чужой_домен>/
- <ваш_домен>/bitrix/rk.php?id=17&site_id=s1&event1=banner&event2=click&goto=<чужой_домен>/
- <ваш_домен>/bitrix/redirect.php?event1=click_to_call&event2=&event3=&goto=<чужой_домен>/
Обычно, подобные массовые ссылки на ваш сайт используются или в целях фишинга, чтобы скрыть домен злоумышленника, или для понижения авторитета вашего сайта в поисковых системах.
Подобные обращения к сайту лучше фильтровать.
На нашем хостинге фильтрация этих ссылок происходит автоматически на основе реферера, однако вы можете отключить эту защиту и обрабатывать условия фильтрации самостоятельно, например в .htaccess или встроенными средствами Битрикса. Они, однако, потребляют значительно больше ресурсов, чем стандартная фильтрация на хостинге.
В том случае, если вы хотите фильтровать ссылки на уровне Битрикса, вам необходимо: