Назад | Перейти на главную страницу

Перенаправление на%-закодированный параметр URL с использованием mod_rewrite в .htaccess

Есть несколько вещей, которые я пытаюсь понять в отношении RewriteRule.

Рабочее правило для URL-адреса отбрасывает запрос обратно на перенаправление, например. URL:

https://www.example.com/application?user=543&AppLink=https://www.example.net/register/reg.aspx?EnquiryID=12345

Рабочая .htaccess код:

RewriteCond %{REQUEST_URI}  ^/application$
RewriteCond %{QUERY_STRING} .*AppLink=(.*)
RewriteRule ^(.*)$ %1 [R=302,L]

Результат (правильно) URL перенаправления:

https://www.example.net/register/reg.aspx?EnquiryID=12345

Все хорошо, пока я не хочу ввести кодировку URL в ссылку запроса, например:

https://www.example.com/application?user=543&AppLink=https%3A%2F%2Fwww.example.net%2Fregister%2Freg.aspx?EnquiryID=12345

Во-первых, введение кодировки нарушает работу RewriteRule, в результате чего возвращается имя http_host - я не понимаю, почему он это делает:

https://www.example.com/https%3A%2F%2Fwww.example.net%2Fregister%2Freg.aspx?EnquiryID=12345

Поэтому я пытаюсь придумать лучший способ "декодирования" / удаления (например) %3A%2F%2F обратно в двоеточия и косую черту перед тем, как он вытянет запрос как действительный URL-адрес для функции перенаправления.

Я предполагаю, что в каком-то смысле мне нужно создать RewriteRule «зацикливания», чтобы привести в порядок кодировку (регулярное выражение), затем перенаправить его на тот же хост, удалить действительный URL-адрес и отправить его на перенаправленный хост!

Да, грязно и над головой.

У кого-нибудь есть предложения или мысли о том, как лучше всего бороться с этим?

... лучший способ атаковать это?

Это действительно задача вашего веб-приложения (например, PHP, Python и т. Д.), А не Apache (.htaccess).

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

https://www.example.com/application?user=543&AppLink=https%3A%2F%2Fwww.domain2.com%2Fregister%2Freg.aspx?EnquiryID=12345

Персонажи : и / не необходимость должны быть закодированы URL-адресом, когда они появляются в части строки запроса URL-адреса. Но если вы правильно закодировали URL-адрес AppLink Значение параметра URL, тогда вы также должны% -кодировать ? и = (часть целевого URL).

Во-первых, введение кодирования нарушает рабочее RewriteRule, в результате чего возвращается имя http_host - я не понимаю, почему он это делает:

В QUERY_STRING переменная сервера не расшифровывается%. Итак, получившийся замена строка:

https%3A%2F%2Fwww.example.net%2Fregister%2Freg.aspx?EnquiryID=12345

Apache / mod_rewrite рассматривает это как относительный URL, потому что он не начинается с косой черты или действительной схемы (т. е. https://). В случае относительного URL-адреса mod_rewrite использует схему и имя хоста (а также префикс каталога или значение RewriteBase директива) из текущего запроса (по умолчанию), чтобы создать абсолютный URL-адрес для внешнее перенаправление, следовательно, вы видите искаженное перенаправление.

Решение

Как отмечалось выше, я бы рекомендовал сделать это в вашем приложении, а не .htaccess. Но в любом случае, чтобы ответить на ваш конкретный вопрос, вы можете сделать что-то вроде следующего вместо ваших текущих директив. Однако для этого требуется Apache 2.4+ и доступ к конфигурации вашего сервера (поскольку AllowEncodedSlashes не разрешено в каталоге /.htaccess контекст):

Следующее должно войти в ваш server-config (или виртуальный хост):

# Allow %2F to be used in the URL-path part of the URL
# Otherwise Apache will trigger a system generated 404 (security feature)
AllowEncodedSlashes On

Затем в .htaccess:

# Convert URL param value to path-info (via URL rewrite)
# This essentially %-decodes the URL parameter value
RewriteCond %{QUERY_STRING} AppLink=(.+)
RewriteRule ^application$ /application/%1 [QSD]

# Issue redirect using the %-decoded URL-path
RewriteRule ^application/(https?:/)(.+) $1/$2 [R,L]

Ноты:

  • По возможности более эффективно проверять URL-путь с помощью RewriteRule шаблон вместо использования дополнительных состояние что сверяется с REQUEST_URI серверная переменная.
  • В QSD Флаг (Query String Discard) необходим для отмены AppLink (и любой другой) параметр URL из исходного запроса.
  • Первая перезапись URL-адреса передается следующей директиве, которая запускает фактическое перенаправление. RewriteRule директивы естественным образом объединяются в цепочку, вывод одной используется как ввод следующей и т. д.
  • URL-путь, по которому RewriteRule шаблон совпадение с% -декодировано. (В то время как QUERY_STRING серверная переменная остается закодированной в%.) Однако непрерывные косые черты в URL-пути сокращаются до одиночных косых черт. Следовательно, проверка только https:/ (не https://) в RewriteRule шаблон и дополнительная косая черта, добавляемая в замена.

Это также предполагает, что в вашей конфигурации разрешена дополнительная информация о пути. Вам может потребоваться явно установить AcceptPathInfo On в .htaccess (или server-config), если нет. Если нет, то вы также получите система сгенерирована 404.