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




webapp start (3)

Ich lese gerade einen Bericht von einer "web application security" Firma, die einige Webseiten der Firma gescannt hat, für die ich arbeite. Aus dem Bericht - der ohne menschliches Zutun geschrieben zu sein scheint - geht hervor, dass mehrere Versuche unternommen wurden, unsere Websites mit folgenden Anfragen zu durchbrechen:

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

Das Ergebnis unseres Servers überrascht mich:

HTTP/1.1 200 OK
Headers: ...

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

Aus früherer Frage zu SO habe ich gelernt, dass das DEBUG Verb in irgendeiner Art von Remote-Debugging von ASP.NET-Anwendungen verwendet wird, aber nicht viele Details sind in dieser Frage oder seinen Antworten verfügbar.

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

Alle Einsichten / Hinweise / Referenzen werden geschätzt.


@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.
Übrigens, wenn die Debug-Kompilierung aktiviert ist, hat sie andere Effekte, da sie mehr Spuren, PDB-Dateien usw. übrig lässt. Nicht unbedingt ein hohes Risiko, aber immer noch ... (ganz zu schweigen von der PCI-Compliance, wenn dies relevant ist.)


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

Wenn der Client versucht, den Debugger automatisch in einer ASP.NET 2.0-Anwendung anzuhängen, 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, um das Debugging durchzuführen - daher bin ich mir nicht bewusst, dass das DEBUG-Verb selbst ein großes Sicherheitsrisiko darstellt (offensichtlich, wenn Sie RPC-Verkehr zulassen, dann haben Sie größere Probleme) oder von irgendwelchen Exploits. UrlScan blockiert es jedoch standardmäßig.

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


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

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

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

Abhängig davon, ob das Debugging aktiviert ist oder nicht, erhalten Sie entweder 200 OK oder 403 Forbidden .

Es wird allgemein akzeptiert, dass Sie in einer Produktionsumgebung niemals <compilation debug="true"/> 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 einen einfachen Weg, um nicht versehentlich <compilation debug="true"/> in Produktions-Websites zu erhalten. machine.config einfach <deployment retail="true"/> zu Ihrer machine.config .

Anscheinend ist <deployment retail="true"/> in der machine.config nicht gleich der Einstellung <compilation debug="false"/> in diesem speziellen Fall. Das Ergebnis von DEBUG Anfragen gegen die Web-Anwendung kann nur mit letzterem geändert werden. Unfassbar!







debugging