Для чего используется нестандартный HTTP-глагол «DEBUG» в ASP.NET/IIS?

Question

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

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 должны знать?

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

Answer 1

Как подсказал Марк, глагол 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 запросов на веб-приложение может быть изменен только с последним. Ошеломляют!

Answer 2

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

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

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

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

Answer 3

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