попытка фишинга через редирект bitrix redirect php

Защита редиректов

Описание

Фишинг (англ. phishing, от password — пароль и fishing — рыбная ловля, выуживание) — вид интернет-мошенничества, целью которого является получение доступа к конфиденциальным данным пользователей (например, логинам и паролям). Это достигается путем проведения массовых рассылок электронных писем от имени популярных брендов, например, от имени социальных сетей, банков, порталов. В письме часто содержится прямая ссылка на сайт, внешне не отличимая от настоящей.

Защита редиректов от фишинга осуществляется двумя методами:

Защита может заключаться в следующих вариантах действий:

Закладка Защита редиректов

Включение или отключение защиты редиректов от фишинга выполняется на странице Защита редиректов от фишинга (Настройки > Проактивная защита > Защита редиректов) с помощью кнопки Включить защиту редиректов от фишинга (Выключить защиту редиректов от фишинга).

Закладка Параметры

Смотрите также

Пользовательские комментарии

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

Для этого нужно всего лишь авторизоваться на сайте

Но помните, что Пользовательские комментарии, несмотря на модерацию, не являются официальной документацией. Ответственность за их использование несет сам пользователь.

Также Пользовательские комментарии не являются местом для обсуждения функционала. По подобным вопросам обращайтесь на форумы.

Источник

Попытка фишинга через редирект

Тоже началось с середины ноября, тоже Timeweb (хотя по сути, хостинг тут ни при чём, конечно же, т. к. идёт «атака» извне).

Надо посмотреть, как снизится в результате нагрузка на CPU, но думаю, что встроенная защита через редирект делает то же самое, что и этот «костыль», просто теперь это не фиксируется в аналитике, и нельзя анализировать, сколько тараканов лезет на наш rk.php. А с каждым днём, между тем, их становится всё больше и больше…

Та же беда, нагрузка растёт и растёт с середины декабря, с 10 до 60%
Попробовал добавить

Order Allow,Deny
Deny from all

php_flag allow_call_time_pass_reference 1
php_flag session.use_trans_sid off
.
.
.

ExpiresActive on
ExpiresByType image/jpeg «access plus 3 day»
ExpiresByType image/gif «access plus 3 day»

Order Allow,Deny
Deny from all

php_flag allow_call_time_pass_reference 1
php_flag session.use_trans_sid off
.
.
.

Источник

Попытка фишинга через редирект

Тоже началось с середины ноября, тоже Timeweb (хотя по сути, хостинг тут ни при чём, конечно же, т. к. идёт «атака» извне).

Надо посмотреть, как снизится в результате нагрузка на CPU, но думаю, что встроенная защита через редирект делает то же самое, что и этот «костыль», просто теперь это не фиксируется в аналитике, и нельзя анализировать, сколько тараканов лезет на наш rk.php. А с каждым днём, между тем, их становится всё больше и больше…

Та же беда, нагрузка растёт и растёт с середины декабря, с 10 до 60%
Попробовал добавить

Order Allow,Deny
Deny from all

php_flag allow_call_time_pass_reference 1
php_flag session.use_trans_sid off
.
.
.

ExpiresActive on
ExpiresByType image/jpeg «access plus 3 day»
ExpiresByType image/gif «access plus 3 day»

Order Allow,Deny
Deny from all

php_flag allow_call_time_pass_reference 1
php_flag session.use_trans_sid off
.
.
.

Источник

Уязвимость Bitrix. Как собрать персональные данные и заспамить недруга

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

Примерно год назад у одного из наших клиентов возникла проблема. Нагрузка на MySQL стала столь значительной, что хостер прислал уведомление следующего вида:

DDoS? Ок, мы принялись изучать, в чем проблема.

Беглый анализ навел на две, одинаково неприятные, мысли:

Еще было подозрение на погоду. Мало ли, надуло.

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

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

Сайты, которые ссылались на наш проект, были, мягко говоря, плохие. Даже не МФА, а просто не пойми что. Очень неприятный звоночек.

Таким способом несколько лет назад валили казахстанские банки. Использовали open redirect для фишингового сбора данных.

Уязвимость позволяет любому сайту закинуть на свою страницу ссылку вида:

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

Как такое возможно? А вот как.

Проблема в родной конфигурации «Битрикс». Это rk.php и redirect.php — служебные файлы, используемые системой для сбора статистики редиректов пользователей при клике по баннерам и ссылкам.

Аналогичная схема может действовать в почтовых рассылках, сообщениях в блогах и социальных сетях и т. д. и т. п. Цель злоумышленника: прикрыться трастовым доменом, чтобы заставить пользователя совершить целевое действие (оставить свои персональные или платежные данные).

Другая цель: испортить представление поисковых систем о вашем сайте. Потому что робот увидит миллион «не тех» ссылок, лучше (хуже) чтобы ссылки шли на что-то совсем неудобоваримое, типа троянов, и накажет. Опять же, скорость и доступность вашего сайта будут ограничены.

Нет однозначного решения, как это исправить. Форумы переполнены болью.

Мы решили бороться по-простому:

Что вы думаете, помогло? Не тут-то было.

Эмоции немножко накалились. И мы стали биться в двери «Битрикс». Что они нам изначально ответили? Ну конечно же, выслали перечень типизированных работ, которые мы уже провели!

Пишем, что все сделали, а результатов нет.

МХАТ. Пауза.

И к нашему великому удивлению решение поддержки было следующим:

Пожалуй, это и смешно, и грустно. Поддержка «Битрикса» рекомендует удалить кусок, пусть и небольшой, собственного продукта. И это помогает.

Напоминаем, проблеме уже не один год. И хотя на официальном форуме «Битрикс» старт обсуждения датируется 2004 годом, никаких упоминаний об этой лазейке в документации нет.

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

Материал подготовлен Еленой Кулишкиной. «Иващенко и Низамов»

В качестве консультанта выступил из сумрака наш разработчик: Илья Соловьев

Читателям SPARK мы предлагаем проверить свой сайт у наших специалистов совершенно бесплатно, заказав SEO-аудит с помощью промокода SPARK1809.

Источник

Инструкция по устранению уязвимости перенаправлений в 1C-Битрикс: Управление сайтом

Данная информация будет полезна государственным учреждениям, сайты которых проходили проверку на безопасность. Если ее итогом стало письмо, содержащее подобную формулировку: “По имеющейся информации официальный сайт ‘название учреждения’ содержит в себе уязвимость информационной безопасности, связанную с функцией перенаправления пользователей в системе управления сайтом “1С-Битрикс”. Указанная уязвимость может быть использована потенциальным нарушителем информационной безопасности. ”, мы расскажем о чем идет речь, и что с этим делать.

Под уязвимостью в данном случае понимают Open Redirect (открытые перенаправления) на вашем сайте. Если при редиректе пользователя не предупреждают о переходе, то сайт могут заподозрить в уязвимости к фишингу.

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

Чтобы все редиректы были защищены, вам нужно:

Авторизоваться в административной части по адресу http://НАЗВАНИЕ_САЙТА/bitrix/ (вместо НАЗВАНИЕ_САЙТА подставьте название вашего сайта), введя ваши логин и пароль.

В левом меню перейти в раздел Настройки-Проактивная защита-Защита редиректов.

Нажать кнопку «Включить защиту редиректов», если выводится сообщение «Защита редиректов от фишинга выключена». Если защита редиректов включена, пропускайте этот шаг.

Перейти во вкладку «Параметры».

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

Применить настройки, нажав кнопку «Сохранить».

Готово! Теперь все редиректы на вашем сайте защищены и соответствуют требованиям безопасности.

Источник