Предотвратить перенаправление открытого URL от гориллы / mux - PullRequest
Новая
       30

Предотвратить перенаправление открытого URL от гориллы / mux

0 голосов
/ 13 марта 2020

Я работаю над веб-приложением RESTful, использующим Go + gorilla / mux v1.4 framework. Некоторые базовые c тесты безопасности после выпуска выявили уязвимость Open URL Redirection в приложении, которая позволяет пользователю отправлять специально созданный запрос с внешним URL-адресом, который заставляет сервер отвечать перенаправлением 301.

Я проверил это с помощью Burp Suite и обнаружил, что любой запрос, который перенаправляет на внешний URL-адрес в приложении, кажется, отвечает 301 Moved Permanently. Я искал все возможные способы перехвата этих запросов перед отправкой 301, но это поведение, похоже, запекается в реализации сервера net / http .

Вот необработанный запрос отправлено на сервер (myapp.mycompany.com:8000): 

GET http://evilwebsite.com HTTP/1.1
Accept: */*
Cache-Control: no-cache
Host: myapp.mycompany.com:8000
Content-Length: 0

И ответ в любое время будет следующим: 

HTTP/1.1 301 Moved Permanently
Location: http://evilwebsite.com/
Date: Fri, 13 Mar 2020 08:55:24 GMT
Content-Length: 0

Несмотря на установку проверок для request.URL для предотвращения этот тип перенаправления в http.handler, мне не повезло получить запрос для достижения обработчика. Похоже, что базовый веб-сервер http выполняет перенаправление, не позволяя ему достичь моего пользовательского кода обработчика, как определено в PathPrefix ("/"). Код обработчика.

Моя цель - обеспечить, чтобы приложение вернуло 404 -Не найдено или 400-Bad запрос на такие запросы. Кто-нибудь еще сталкивался с этим сценарием с гориллой / муксом? Я попробовал то же самое с веб-приложением Jetty и обнаружил, что оно вернуло совершенно верный 404. Я занимался этим уже пару дней и действительно мог бы использовать некоторые идеи.

1 Ответ

0 голосов
/ 13 марта 2020

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

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

...