Jaki jest niestandardowy czasownik HTTP "DEBUG" używany w ASP.NET/IIS?

Question

Czytam raport z firmy "ochrona aplikacji internetowych", która skanowała kilka stron internetowych firmy, nad którą pracuję. Jak wynika z raportu - który wydaje pisemną bez udziału człowieka - że kilka prób, gdzie wykonane złamać nasze strony za pomocą żądań tak:

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

Wynik z naszego serwera zaskakuje mnie:

HTTP/1.1 200 OK 
Headers: ... 

Ponieważ DEBUG nie wydaje się być nigdzie w nazwie w HTTP 1.1 specification, oczekiwałbym, że wynik będzie 400 Bad Request lub 405 Method Not Allowed.

Od earlier question on SO, nauczyłem się, że czasownik DEBUG jest używany do pewnego zdalnego debugowania aplikacji ASP.NET, ale w tym pytaniu lub jego odpowiedziach nie ma zbyt wielu szczegółów.

Dokładnie jaki jest czasownik DEBUG używany? Dlaczego aplikacja używa adresu 200 OK w przypadku nieprawidłowych adresów URL? Czy to jest problem z bezpieczeństwem? Czy są jakieś potencjalne problemy bezpieczeństwa związane z czasownikiem DEBUG, o którym powinni wiedzieć deweloperzy/administratorzy systemów ASP.NET?

Wszelkie uwagi/porady/referencje zostaną docenione.

Answer 1

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

Gdy klient próbuje automatycznie dołączyć debugera w aplikacji ASP.NET 2.0, klient wysyła żądanie HTTP, który zawiera czasownik debugowania. To żądanie HTTP służy do sprawdzania, czy działa proces aplikacji i wyboru prawidłowego procesu, który ma zostać dołączony.

Wykorzystuje uwierzytelnianie systemu Windows, a DCOM faktycznie zrobić debugowanie chociaż - więc nie jestem świadomy czasownika DEBUG samego będącego dużym ryzykiem bezpieczeństwa (oczywiście, jeśli jesteś umożliwiając ruch RPC, a następnie” mają większe problemy) lub jakichkolwiek exploitów. UrlScan domyślnie blokuje to.

Prawdopodobnie założyłem na nim sniffer sieciowy, aby sprawdzić, jakie informacje przeciekają.

Answer 2

Zgodnie z sugestią Marka, czasownik DEBUG służy do uruchamiania/zatrzymywania sesji zdalnego debugowania. Dokładniej, żądanie DEBUG może zawierać nagłówek Command o wartości start-debug i stop-debug, ale rzeczywiste debugowanie odbywa się za pośrednictwem protokołu RPC.

Dlaczego skaner bezpieczeństwa wykonuje takie żądanie? Wygląda na to, że wskrzeszanie strony ASP.NET za pomocą żądań DEBUG może być użyte do ujawnienia, czy web.config ma . Test można wykonać z telnet, WFetch lub podobne, przez wysłanie żądania takiego:

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

W zależności od tego, czy debugowanie jest włączone czy nie, dostaniesz albo 200 OK lub 403 Forbidden.

To jest generallyaccepted, że nigdy nie powinieneś mieć <compilation debug="true"/> w środowisku produkcyjnym, ponieważ ma to poważne konsekwencje dla wydajności witryny. Nie jestem pewien, czy po włączeniu debugowania otwierają się nowe wektory ataku, chyba że ruch RPC jest również włączony, w takim przypadku i tak masz poważniejsze problemy (patrz odpowiedź Marka). Wszelkie dodatkowe informacje na temat perspektywy bezpieczeństwa będą bardzo mile widziane.

Istnieje prosty sposób na uniknięcie przypadkowego pobrania <compilation debug="true"/> w witrynach produkcyjnych. Po prostu dodaj <deployment retail="true"/> do swojego machine.config.

Najwyraźniej mając <deployment retail="true"/> w machine.config jest nie równe ustawienie <compilation debug="false"/> w tym konkretnym przypadku. Wynik rzucania żądań DEBUG przeciwko aplikacji internetowej może być zmieniony tylko z tymi ostatnimi. Zadziwiające!

Answer 3

@ Mark, @ Jørn, dzięki za doskonałą informację, byłem również ciekaw tego.
Co do raportu, z punktu widzenia bezpieczeństwa, jest jeszcze jeden aspekt (oprócz RPC i wsparcia debugowania) - powierzchnia ataku. Jest to rodzaj elementu niskiego ryzyka, ale najlepszą praktyką jest zazwyczaj minimalizowanie zewnętrznych interfejsów, których nie potrzebujesz, aby potencjalni napastnicy mieli mniej miejsca na manewry i mieli mniejsze prawdopodobieństwo znalezienia tej jednej krytycznej usterki.
Btw, włączenie kompilacji debugowania ma inne efekty, ponieważ pozostawia więcej śladów, plików pdb itp. Niekoniecznie wysokie ryzyko, ale nadal ... (nie wspominając o zgodności z PCI, jeśli jest to istotne.)