Уязвимость перенаправления URL через rk.php и redirect.php

Главная

Помощь

Аренда VPS

Bitrix CMS — это популярная система управления контентом, которая используется для создания сайтов и онлайн-магазинов. Однако, как и любое другое веб-приложение, Bitrix CMS может иметь уязвимости, которые могут быть использованы злоумышленниками для атак на сайт. Одной из таких уязвимостей является уязвимость, связанная с редиректом на rk.php и redirect.php.

Как работают редиректы на rk.php и redirect.php в Bitrix CMS?

В Bitrix CMS, rk.php и redirect.php — это файлы, которые используются для перенаправления пользователей на другие страницы. Например, если пользователь вводит неправильный адрес страницы, он может быть перенаправлен на страницу с ошибкой или на другую страницу сайта. Для перенаправления пользователя эти файлы используются в сочетании с параметрами URL, которые указывают, на какую страницу нужно перенаправить пользователя.

Что такое уязвимость связанная с редиректом на rk.php и redirect.php в Bitrix CMS?

Уязвимость связанная с редиректом на rk.php и redirect.php в Bitrix CMS заключается в том, что злоумышленники могут использовать эти файлы для перенаправления пользователей на другие сайты или страницы, которые могут содержать вредоносный код. Например, злоумышленник может создать ложную страницу авторизации и использовать rk.php или redirect.php, чтобы перенаправить пользователя на эту страницу. Затем злоумышленник может попросить пользователя ввести свои учетные данные, которые будут использованы для несанкционированного доступа к его учетной записи.

Как избежать уязвимости связанной с редиректом на rk.php и redirect.php в Bitrix CMS?

Чтобы избежать уязвимости связанной с редиректом на rk.php и redirect.php в Bitrix CMS, следует использовать только надежные и проверенные источники перенаправления. Никогда не следует нажимать на ссылки, которые вы получили от незнакомых источников или которые вы не ожидали получить. /bitrix/(rk|redirect)\.php$ {         deny all;     }     … }

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

sudo service nginx restart

или если вы используйте systemd

sudo systemctl restart nginx

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

В заключение, уязвимость связанная с редиректом на rk.php и redirect.php в Bitrix CMS является серьезной угрозой для безопасности сайта. Чтобы избежать этой уязвимости, следует использовать только надежные и проверенные источники перенаправления, использовать проверку пользовательского ввода и отфильтровывать неправильные URL-адреса, а также использовать дополнительные методы безопасности. Добавление правила в конфигурационный файл Nginx также поможет защитить ваш сайт от уязвимости связанной с редиректом на rk.

php и redirect.php в Bitrix CMS.

Остались вопросы — пишите

Вопрос для отдела

Отдел продаж

Тех. поддержка

Бухгалтерия

Логин:

Пароль:

Переадресация внутри сайта с помощью .htaccess

🏠 | 💻 PC | Web |

↓ Contents ↓

	Introduction
	Как сделать переадресацию
	Как сделать несколько редиректов
	Решение проблем

Introduction

Прежде, чем заниматься переадресацией, нужно выяснить тип сервера, на котором размещён Ваш сайт.

Файл .htaccess вносит изменения в работу сервера Apache

В Nginx похожой цели служит файл nginx.conf суть там та же, но синтаксис немного другой.

Простая постоянная переадресация 301

To перенестри страницу с одного адреса на другой на постоянной основе вносите в .htaccess следующие изменения:

RewriteEngine on Redirect 301 old_url http://адрес_новой_страницы

Где old_url это адрес_старой_страницы_относительно_корня_сайта

Если ваш сервер это Apache, a файла .htaccess у Вас нет, можете создать его самостоятельно и поместить, например, в корневую директорию.

Пример

RewriteEngine on Redirect 301 /old_dir/url1.php /new_dir/url1.php Redirect 301 /old_url1.php /new_url.php Redirect 301 /old_url2.

php /new_dir/new_url.php

Можно сделать переадресацию целой директории

RewriteEngine on Redirect 301 /old_dir /new_dir

Два редиректа

Если вы делаете два редиректа, которые влияют на какую-то страницу, например перенаправляете целую директорию, и ещё дополнительно что-то меняете внутри — нужно делать это аккуратно

Допустим было:

/old_dir/a.php
/old_dir/b.php
/old_dir/c.php

А теперь нужно:

/new_dir/a.php
/new_dir/b.php
/new_dir/new_c.php

Для переадресации a.php и b.php достаточно создать правило

Redirect 301 /old_dir /new_dir

А вот чтобы правильно перенаправить

с.php в new_c. php нужно мысленно представить, куда перенаправится старый с.php с учётом нашего редиректа Redirect 301 /old_dir /new_dir

Как вы наверное и сами догадались, перенаправится он из

/old_dir/c.php

в

/new_dir/c.php

И уже вот этот несуществующий /new_dir/c.php нам нужно перенаправить в

/new_dir/new_c.php

Поэтому правило будет выглядеть следующим образом

Redirect 301 /old_dir /new_dir Redirect 301 /new_dir/c.php /new_dir/new_c.php

Дебаг

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

У хостинга Beget которым я пользуюсь, и вам могу порекомендовать — логи с ошибками доступа лежат в файле

sitename. xx.error.log

Когда я хочу проверить, что не так — я логинюсь на хостинг по ssh захожу к себе в public_html и делаю

tail -n 100 aredel.com.error.log

Так я вижу последние 100 строк сегодняшнего лога. И если бы там было

… script ‘/home/xxx/aredel.com/public_html/new_dir/c.php’ not found or unable to start, referer heihei.ru

Я бы понял, что не настроена переадресация со старого c.php на новый new_c.php и добавил бы строку

Redirect 301 /new_dir/c.php /new_dir/new_c.php

В

.htaccess

Подробнее про работу с логами читайте в моей статье про тестирование

Также советую изучить команды Bash

Роботы:
207.46.13.56 bing

Related Articles:

	🛠	Полезные советы
	🖽	Html
	🖌	CSS
		Joomla
		UTM-метки
		URLencode
	↬	Переадресация страниц сайта
	↔	Адаптивный дизайн сайтов
		Настройка почтового ящика на Яндекс
		Какой хостинг выбрать
		Как перенести сайт
		Яндекс Метрика
		Разница между POST и PUT
		Word Press
		SEO
		Тестирование сайта
		A numeric character reference expanded to the C1 controls range.
		JavaScript
		.webp
		Flask
		Django
		Как указать каноническую страницу сайта

• Search on this website
• aofeed — Telegram channel for updates
• aofeedchat — Telegram group for questions

Share in social media:

Контроллер

(Symfony Docs)

Изменить эту страницу

Контроллер — это созданная вами функция PHP, которая считывает информацию из Объект Request , создает и возвращает объект Response . Ответ может быть HTML-страницей, JSON, XML, загрузкой файла, перенаправлением, ошибкой 404 или чем-то еще еще. Контроллер запускает любую произвольную логику вашего приложения потребности для отображения содержимого страницы.

Кончик

Если вы еще не создали свою первую рабочую страницу, проверьте Создайте свою первую страницу в Symfony, а затем возвращайтесь!

В то время как контроллер может быть любым вызываемым PHP (функцией, методом объекта, или Closure ), контроллер обычно является методом внутри контроллера class:

Контроллер — это метод number() , который находится внутри класс контроллера ЛакиКонтроллер .

Этот контроллер довольно прост:

• строка 2 : Symfony использует функциональность пространства имен PHP для пространство имен весь класс контроллера.
• строка 4 : Symfony снова использует функциональность пространства имен PHP: ключевое слово use импортирует класс Response , который контроллер должен вернуться.
• строка 7 : Технически класс можно назвать как угодно, но он имеет суффикс с Контроллер по соглашению.
• строка 10 : методу действия разрешено иметь аргумент $max благодаря {max} подстановочный знак в маршруте.
• строка 14 : Контроллер создает и возвращает объект Response .

Чтобы просмотреть результат этого контроллера, вам необходимо сопоставить URL-адрес с ним через маршрут. Это было сделано выше с помощью #[Route('/lucky/number/{max}')] атрибут маршрута.

Чтобы увидеть свою страницу, перейдите по этому URL-адресу в браузере: http://localhost:8000/lucky/number/100

Дополнительную информацию о маршрутизации см. в разделе Маршрутизация.

Для облегчения разработки Symfony поставляется с необязательным базовым классом контроллера, называемым АбстрактныйКонтроллер. Его можно расширить, чтобы получить доступ к вспомогательным методам.

Добавьте оператор use поверх вашего класса контроллера, а затем измените LuckyController для расширения:

Всё! Теперь у вас есть доступ к таким методам, как $this->render(). и многие другие, о которых вы узнаете далее.

Генераторурл() метод является просто вспомогательным методом, который генерирует URL-адрес для данного маршрута:

Если вы хотите перенаправить пользователя на другую страницу, используйте redirectToRoute() и метода перенаправления() :

Осторожность

Метод redirect() никак не проверяет свое назначение. Если вы перенаправить на URL-адрес, предоставленный конечными пользователями, ваше приложение может быть открыто к уязвимости безопасности непроверенных перенаправлений.

Если вы обслуживаете HTML, вам нужно отобразить шаблон. Рендер () метод отображает шаблон , а помещает это содержимое в ответ объект для вас:

Шаблоны и Twig более подробно описаны в Статья Создание и использование шаблонов.

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

Если вам нужна служба в контроллере, введите аргумент с его классом (или интерфейса) имя. Symfony автоматически передаст вам нужный сервис:

Отлично!

Какие еще услуги можно подсказать? Чтобы увидеть их, используйте консоль debug:autowiring . команда:

Кончик

Если вам нужен контроль над точным значением аргумента или требуется параметр, можно использовать #[Autowire] 9Атрибут 0004:

Подробнее об этом атрибуте можно прочитать в разделе Автоматическое определение зависимостей служб (автоматическое подключение).

6.1

Атрибут #[Autowire] был представлен в Symfony 6.1.

Как и все услуги, вы также можете использовать обычные инъекция конструктора в ваш контроллеры.

Дополнительные сведения о службах см. в статье о контейнере служб.

Чтобы сэкономить время, вы можете установить Symfony Maker и указать Symfony сгенерировать новый класс контроллера:

Если вы хотите сгенерировать весь CRUD из объекта Doctrine, используйте:

Если что-то не найдено, вы должны вернуть ответ 404. Для этого бросьте особый тип исключения:

метод - это просто ярлык для создания специального NotFoundHttpException объект, который в конечном итоге вызывает HTTP-ответ 404 внутри Symfony.

Если вы создаете исключение, которое расширяет или является экземпляром HttpException, Symfony будет используйте соответствующий код состояния HTTP. В противном случае ответ будет иметь 500 Код состояния HTTP:

В любом случае конечному пользователю показывается страница с ошибкой и полная отладка. страница с ошибкой показывается разработчику (т.е. когда вы находитесь в режиме "Отладка" - см. Настройка Symfony).

Чтобы настроить страницу ошибки, отображаемую пользователю, см. Как настроить страницы ошибок.

Что делать, если вам нужно прочитать параметры запроса, получить заголовок запроса или получить доступ в загруженный файл? Эта информация хранится в Symfony Request . объект. Чтобы получить к нему доступ в вашем контроллере, добавьте его в качестве аргумента и введите его с классом запроса :

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

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

Например, представьте, что вы обрабатываете отправку формы:

Дополнительная информация об использовании сеансов.

Как упоминалось ранее, Symfony передайте объект Request любому аргументу контроллера, который имеет подсказку типа с помощью класс Request :

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

Как и Request , объект Response имеет общедоступное свойство headers . Этот объект имеет тип ResponseHeaderBag. и предоставляет методы для получения и установки заголовков ответа. Имена заголовков нормализовано. В результате имя Content-Type эквивалентен имя content-type или content_type .

В Symfony требуется, чтобы контроллер возвращал объект Response :

Чтобы облегчить это, включены разные объекты ответа для адресации разных типы ответов. Некоторые из них упомянуты ниже. Чтобы узнать больше о Request и Response (и разные классы Response ), см. Документация по компоненту HttpFoundation.

Чтобы получить значение любого параметра конфигурации из контроллера используйте вспомогательный метод getParameter() :

Чтобы вернуть JSON из контроллера, используйте вспомогательный метод json() . Это возвращает Объект JsonResponse , автоматически кодирующий данные:

Если в вашем приложение, оно будет использоваться для сериализации данных в JSON. В противном случае, используется функция json_encode.

Вы можете использовать файл() помощник для обслуживания файла изнутри контроллера:

Помощник file() предоставляет несколько аргументов для настройки своего поведения:

В Symfony контроллер обычно является методом класса, который используется для принятия запросы и вернуть объект Response . При сопоставлении с URL-адресом контроллер становится доступным, и его ответ можно просмотреть.

Для облегчения разработки контроллеров Symfony предоставляет Абстрактный Контроллер . Его можно использовать для расширения класса контроллера, позволяющего доступ к некоторым часто используемым утилитам, таким как рендер() и redirectToRoute() . AbstractController также обеспечивает createNotFoundException() Утилита , используемая для возврата страницы, которая не найдена ответ.

В других статьях вы узнаете, как использовать определенные службы внутри вашего контроллера. которые помогут вам сохранять и извлекать объекты из базы данных, обрабатывать отправленные формы, обрабатывать кэширование и многое другое.

Далее узнайте все о рендеринге шаблонов с помощью Twig.

• Как настроить страницы ошибок
• Как перенаправить запросы на другой контроллер
• Как определить контроллеры как службы
• Как загружать файлы 0

  Эта работа, включая образцы кода, лицензирована Creative Commons BY-SA 3. 0 лицензия.

  Версия

  Redirect Regular Expressions — Redirection

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

  Регулярное выражение (или регулярное выражение) — это группа символов, используемая для поиска шаблона в фрагменте текста.

  В контексте перенаправления совпадение простого URL-адреса будет соответствовать только одному URL-адресу. URL-адрес регулярного выражения может соответствовать многим URL-адресам.

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

  Несколько примеров могут оказаться полезными. Перенаправление с исходным URL /my-url  будет соответствовать только запросам с /my-url .

  Перенаправление с исходным URL /my-url/.*  соответствует запросам:

  • /my-url/this
  • /my-url/that

  И так далее.

  Важная часть /my-url/.*  это .* ​. Это часть URL-адреса, состоящая из регулярных выражений, и она эквивалентна фразе «сопоставить /my-url/  с любой последовательностью символов».

  Обратите внимание: чтобы включить соответствие регулярному выражению в перенаправлении, убедитесь, что вы включили параметр «регулярное выражение».

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

  Синтаксис регулярных выражений

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

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

  Но подождите, все гораздо сложнее!

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

  Извлечение информации об источнике

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

  Зачем тебе это? Давайте посмотрим на другой пример. Допустим, у вас есть сайт, некоторые страницы которого находятся в каталоге /oldpage/, и вы переместили их в каталог /newpage/.

  • /oldpage/bananas/
  • /oldpage/best-post-in-the-world/ ​

  И вы хотите переместить их по адресу:

  • /newpage/bananas/
  • /newpage/best-post-in-the-world/

  То есть вы хотите изменить /oldpage/  до /newpage/ , но сохраните банана  и лучший пост в мире .

  Для этого вы можете создать регулярное выражение, такое как /oldpage/(.*) .

  Обратите внимание, что .*  обведено квадратными скобками. Это говорит Redirection «захватить» данные. Тогда целевой URL будет /newpage/$1 .

  Здесь $1 заменяется содержимым захваченного (.*) . Итак:

  /oldpage/bananas  => /oldpage/(bananas)  => /newpage/$1  => /newpage/bananas

  Бесконечные циклы

  Часто возникающая проблема с регулярным выражением это бесконечное перенаправление . То есть вы создаете регулярное выражение, которое перенаправляет на URL-адрес, который сам перехватывается тем же регулярным выражением. Затем он перенаправляется снова, и снова, и снова, пока браузер не остановится с Сообщение ERR_TOO_MANY_REDIRECTS (или эквивалентное).

  Например, скажем, у нас есть это перенаправление:

  /index. php/(.*) => /portal/index.php/$1

  Если вы заходите на /index.php/banana ​затем он будет перенаправлен на /portal/index.php/banana . Но ждать! Сам URL-адрес /portal/index.php/banana соответствует исходному регулярному выражению, поскольку index.php/banana соответствует /portal/ index.php/(.*) 9  указывает регулярному выражению, что оно применяется только при совпадении в начале URL. Это предотвращает его совпадение в другом месте URL-адреса и останавливает бесконечную переадресацию.

  Тестирование регулярных выражений

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

  • https://regexr.com/
  • https://regex101.com/

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

  Хороший ресурс для понимания регулярных выражений можно найти здесь.

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

  Соответствие всему URL-адресу

  Перенаправление выполняет замену регулярного выражения – preg_replace . Источником перенаправления является шаблон соответствия, целью является шаблон замены, а запрошенный URL-адрес — это тема.

  Это означает, что будет заменен только соответствующий контент. Если вы не совпадаете со всем URL-адресом, будет заменена только та его часть, а остальная часть URL-адреса будет добавлена. Это ожидаемое поведение, и именно так работают регулярные выражения.

  Обратите внимание, что в этом контексте термин «полный URL» относится ко всему, кроме протокола и домена.

  Общие регулярные выражения

  Следующие регулярные выражения обычно используются для WordPress. Как упоминалось выше, вам нужно будет включить опцию regex .

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

  Дата перенаправления и имя постоянная ссылка 9/(?!blog)(.*)

  Target

  /blog/$1

  Перенаправить каждую страницу старого сайта на новый сайт
  http://oldsite.com/your-thing/ 9000 4 ⇒ https://newsite.com/your-thing/
Возможно, вам будет проще использовать Site Relocate .

  Источник

  /(.*)

  Цель

  https://newsite.