Was ist das nicht standardmäßige HTTP-Verb "DEBUG", das in ASP.NET/IIS verwendet wird?

Question

Ich lese einen Bericht von einer "Web Application Security" Firma, die einige Webseiten der Firma gescannt habe, für die ich arbeite. Es scheint aus dem Bericht -, die ohne menschliches Zutun geschrieben scheint - dass mehrere Versuche gemacht, wo unsere Websites zu brechen diese mit Anfragen wie:

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

Das Ergebnis von unserem Server überrascht mich:

HTTP/1.1 200 OK 
Headers: ... 

Da DEBUG nicht irgendwo in der HTTP 1.1 specification erwähnt zu sein scheint, hätte ich erwartet, dass das Ergebnis 400 Bad Request oder 405 Method Not Allowed ist.

Von earlier question on SO, habe ich gelernt, dass das Verb DEBUG in einer Art Remote-Debuggen von ASP.NET-Anwendungen verwendet wird, aber nicht viele Details sind in dieser Frage oder ihre Antworten verfügbar.

Genau was ist das DEBUG Verb für verwendet? Warum antwortet die Anwendung bei Verwendung dieses Verbs auf ungültige URLs mit 200 OK? Ist das ein Sicherheitsproblem? Gibt es potenzielle Sicherheitsprobleme im Zusammenhang mit dem Verb DEBUG, das ASP.NET-Entwickler/Systemadministratoren kennen sollten?

Alle Einsichten/Hinweise/Referenzen werden geschätzt.

Answer 1

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

Wenn der Client versucht, automatisch den Debugger in einer ASP.NET 2.0-Anwendung zu befestigen, sendet der Client eine HTTP-Anforderung, die das DEBUG Verb enthält. Diese HTTP-Anfrage wird verwendet, um zu überprüfen, dass der Prozess der Anwendung ausgeführt wird, und um den richtigen anzuhängenden Prozess auszuwählen.

Es verwendet die Windows-Authentifizierung, und DCOM tatsächlich obwohl das Debuggen zu tun - so bin ich keine Kenntnis von dem DEBUG Verb selbst ein großes Sicherheitsrisiko (offensichtlich zu sein, wenn Sie RPC-Verkehr sind erlaubt, Ihnen dann‘ Ich habe größere Probleme) oder irgendwelche Exploits. UrlScan blockiert es jedoch standardmäßig.

Ich würde wahrscheinlich einen Netzwerk-Sniffer darauf setzen, um zu prüfen, welche Informationen jedoch auslaufen.

Answer 2

Wie von Mark angedeutet, wird das Verb DEBUG zum Starten/Stoppen von Remote-Debugging-Sitzungen verwendet. Genauer gesagt kann eine DEBUG Anfrage einen Command Header mit dem Wert start-debug und stop-debug enthalten, aber das eigentliche Debugging erfolgt über ein RPC-Protokoll.

Warum führt ein Sicherheitsscanner diese Anforderung aus? Es scheint, dass das Stochern einer ASP.NET-Website mit den DEBUG Anforderungen verwendet werden kann, um zu zeigen, ob die web.config<compilation debug="true"> hat. Der Test kann mit Telnet durchgeführt werden, WFetch oder ähnliches, durch eine Anfrage wie folgt zu senden:

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

Je nachdem, ob das Debuggen aktiviert ist oder nicht, werden Sie entweder 200 OK oder 403 Forbidden bekommen.

Es ist generallyaccepted, dass Sie niemals <compilation debug="true"/> in einer Produktionsumgebung haben sollten, da dies schwerwiegende Auswirkungen auf die Leistung der Website hat. Ich bin mir nicht sicher, ob das Debuggen aktiviert neue Angriffsvektoren öffnet, es sei denn, auch der RPC-Verkehr ist aktiviert. In diesem Fall haben Sie ohnehin ernstere Probleme (vgl. Marks Antwort). Alle zusätzlichen Einblicke in die Sicherheitsperspektive werden sehr geschätzt.

Es gibt eine einfache Möglichkeit zu vermeiden, versehentlich <compilation debug="true"/> in Produktion Websites zu bekommen. Fügen Sie einfach <deployment retail="true"/> zu Ihrem machine.config hinzu.

Offenbar in den machine.config<deployment retail="true"/> aufweisen, ist nicht gleich <compilation debug="false"/> in diesem besonderen Fall der Einstellung. Das Ergebnis von DEBUG Anfragen gegen die Webanwendung kann nur mit letzterem geändert werden. Unfassbar!

Answer 3

@Mark, @ Jørn, danke für die hervorragenden Infos, ich war auch neugierig darauf.
Was den Bericht betrifft, gibt es unter dem Gesichtspunkt der Sicherheit einen weiteren Aspekt (außer RPC und Debugging-Unterstützung): Angriffsfläche. Ich bin ein wenig risikobehaftet, aber die beste Vorgehensweise besteht darin, externe Schnittstellen, die Sie nicht benötigen, zu minimieren, so dass potentielle Angreifer weniger Spielraum haben und eine geringere Wahrscheinlichkeit haben, diesen einen kritischen Fehler zu finden.
Btw, mit Debug Compilation aktiviert hat andere Effekte, wie es mehr Spuren, Pdb-Dateien, usw. um. Nicht unbedingt ein hohes Risiko, aber immer noch ... (ganz zu schweigen von der PCI-Konformität, wenn dies relevant ist.)