Что такое нестандартный HTTP-глагол "DEBUG", используемый в ASP.NET/IIS?

Я читаю отчет от компании "Безопасность веб-приложений", которая просматривает несколько веб-сайтов компании, над которой я работаю. Из отчета, который, как представляется, написано без какой-либо человеческой заинтересованности, видно, что было предпринято несколько попыток разбить наши сайты с использованием таких запросов:

DEBUG /some_path/some_unexisting_file.aspx
Accept: */*
More-Headers: ...

Результат от нашего сервера удивляет меня:

HTTP/1.1 200 OK
Headers: ...

Как DEBUG, кажется, нигде не упоминается в Спецификация HTTP 1.1 Я ожидал, что результатом будет 400 Bad Request или 405 Method Not Allowed.

Из более раннего вопроса о SO, я узнал, что глагол DEBUG используется в виде удаленной отладки приложений ASP.NET, но не так много деталей доступны в этом вопросе или его ответах.

Точно, для чего используется глагол DEBUG? Почему приложение отвечает 200 OK за недопустимые URL-адреса при использовании этого глагола? Это проблема безопасности? Существуют ли какие-либо потенциальные проблемы безопасности, связанные с глаголом DEBUG, о которых должны знать разработчики/системные администраторы ASP.NET?

Любые идеи/рекомендации/ссылки будут оценены.

Ответы

Ответ 1

http://support.microsoft.com/kb/937523

Когда клиент пытается автоматически присоединить отладчик в приложении ASP.NET 2.0, клиент отправляет HTTP-запрос, содержащий глагол DEBUG. Этот HTTP-запрос используется для проверки выполнения процесса приложения и выбора правильного процесса для присоединения.

Он использует проверку подлинности Windows и DCOM, чтобы на самом деле выполнять отладку, поэтому - я не знаю, что глагол DEBUG сам по себе является большой угрозой безопасности (очевидно, если вы разрешаете RPC-трафик, то у вас больше проблемы) или любых эксплойтов. Однако UrlScan блокирует его по умолчанию.

Я бы, вероятно, поставил на него сетевой сниффер, чтобы проверить, какая информация протекает.

Ответ 2

Как намекнул Марк, глагол DEBUG используется для запуска/остановки сеансов удаленной отладки. Более конкретно, запрос DEBUG может содержать заголовок Command со значением start-debug и stop-debug, но фактическая отладка выполняется через протокол RPC.

Итак, почему сканер безопасности выполняет такой запрос? Похоже, что поиск веб-сайта ASP.NET с запросами DEBUG может быть использован, чтобы показать, имеет ли web.config <compilation debug="true">. Тест можно выполнить с помощью telnet, WFetch или аналогичного, отправив запрос следующим образом:

DEBUG /foo.aspx HTTP/1.0
Accept: */*
Host: www.example.com
Command: stop-debug

В зависимости от того, включена ли отладка или нет, вы получите либо 200 OK, либо 403 Forbidden.

обычно принят, что вы никогда не должны иметь <compilation debug="true"/> в производственной среде, так как это имеет серьезные последствия для эффективности веб-сайта. Я не уверен, что если отладка включена, открывает все новые векторы атаки, если RPC-трафик не включен, и в этом случае у вас есть более серьезные проблемы в любом случае (см. Отклик ответа). Будем очень благодарны за любые дополнительные идеи в отношении безопасности.

Существует простой способ избежать случайного получения <compilation debug="true"/> на веб-сайтах. Просто добавьте <deployment retail="true"/> к вашему machine.config.

По-видимому, наличие <deployment retail="true"/> в machine.config не, равное установке <compilation debug="false"/> в данном конкретном случае. Результат запроса метаданных DEBUG на веб-приложение может быть изменен только последним. Ошеломляют!

Ответ 3

@Mark, @Jørn, спасибо за отличную информацию, мне также было любопытно об этом.
Что касается вашего отчета, с точки зрения безопасности есть еще один аспект (помимо RPC и поддержка отладки) - поверхность атаки. Я вроде бы низкорентабельный элемент, но наилучшая практика заключается в том, чтобы свести к минимуму любые внешние интерфейсы, которые вам не нужны, чтобы потенциальные злоумышленники имели меньше возможностей для маневра и имели меньшую вероятность найти один критический недостаток.
Btw, с включенной отладкой компиляции, имеет другие эффекты, так как он оставляет больше следов, файлов pdb и т.д. Не обязательно высокий риск, но все же... (не говоря уже о соблюдении PCI, если это имеет значение.)