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

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

Это действительно задача для вашего веб-приложения (например, 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 ] (Отменить строку запроса)требуется, чтобы исключить AppLink (и любой другой) параметр URL из первоначального запроса.
• Первая перезапись URL передается следующей директиве, которая запускает фактическое перенаправление. Директивы RewriteRule естественным образом объединяются в цепочку, выходные данные одной используются в качестве входных данных следующей и т. Д.
• URL-путь, которому соответствует шаблон RewriteRule против расшифровывается%. (В то время как серверная переменная QUERY_STRING остается закодированной в%.) Однако непрерывные косые черты в URL-пути сокращаются до одиночных косых черт. Следовательно, проверка только https: / (не https: // ) в шаблоне RewriteRule и дополнительная косая черта, добавляемая в замена .

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