Debuggersicherheit

Die Möglichkeit, einen anderen Prozess zu debuggen, bietet Ihnen extrem breite Befugnisse, die Sie sonst nicht haben würden, insbesondere beim Remotedebugging. Ein böswilliger Debugger könnte weit verbreiteten Schaden auf dem Computer verursachen, der gedebuggt wird.

Viele Entwickler erkennen jedoch nicht, dass die Sicherheitsrisiken auch in die entgegengesetzte Richtung fließen können. Es ist möglich, dass bösartiger Code im Debuggee-Prozess die Sicherheit des Debugcomputers gefährdet: Es gibt eine Reihe von Sicherheits-Exploits, die geschützt werden müssen.

Bewährte Methoden für Sicherheit

Es gibt eine implizite Vertrauensstellung zwischen dem Code, den Sie debuggen, und dem Debugger. Wenn Sie bereit sind, etwas zu debuggen, sollten Sie auch bereit sein, etwas auszuführen. Die untere Linie besteht darin, dass Sie in der Lage sein müssen, dem zu vertrauen, was Sie debuggen. Wenn Sie ihm nicht vertrauen können, sollten Sie es nicht debuggen oder es von einem Computer debuggen, den Sie riskieren können, und dabei in einer isolierten Umgebung arbeiten.

Um die potenzielle Angriffsfläche zu reduzieren, sollte das Debuggen auf Produktionscomputern deaktiviert werden. Aus demselben Grund sollte das Debuggen niemals unbegrenzt aktiviert werden.

Verwaltete Debuggingsicherheit

Im Folgenden finden Sie einige allgemeine Empfehlungen, die für alle verwalteten Debuggings gelten.

• Achten Sie beim Anfügen an den Prozess eines nicht vertrauenswürdigen Benutzers darauf: Wenn Sie dies tun, gehen Sie davon aus, dass er vertrauenswürdig ist. Wenn Sie versuchen, auf den Prozess eines nicht vertrauenswürdigen Benutzers zuzugreifen, erscheint ein Dialogfeld mit einer Sicherheitswarnung, das Sie fragt, ob Sie den Prozess anfügen möchten. "Vertrauenswürdige Benutzer" umfassen Sie und eine Reihe von Standardbenutzern, die häufig auf Computern definiert sind, auf denen .NET Framework installiert ist, z. B. aspnet, localsystem, networkservice und localservice. Weitere Informationen finden Sie unter Sicherheitswarnung: Das Anfügen an einen Prozess, der einem nicht vertrauenswürdigen Benutzer gehört, kann gefährlich sein. Wenn die folgenden Informationen verdächtig aussehen oder Sie unsicher sind, fügen Sie diesen Vorgang nicht an.

• Achten Sie beim Herunterladen eines Projekts aus dem Internet darauf und reihen Sie es dann in Visual Studio ein. Dies ist sehr riskant, selbst ohne zu debuggen. In diesem Fall wird davon ausgegangen, dass das Projekt und der darin enthaltene Code vertrauenswürdig sind.

  Weitere Informationen finden Sie unter Debuggen von verwaltetem Code.

Remotedebuggingsicherheit

Das lokale Debuggen ist im Allgemeinen sicherer als das Remotedebugging. Das Remotedebugging erhöht den gesamten Oberflächenbereich, der untersucht werden kann.

Der Visual Studio-Remotedebuggingmonitor (msvsmon.exe) wird im Remotedebugging verwendet, und es gibt mehrere Sicherheitsempfehlungen für die Konfiguration. Die bevorzugte Methode zum Konfigurieren des Authentifizierungsmodus ist die Windows-Authentifizierung, da kein Authentifizierungsmodus unsicher ist.

Beachten Sie bei der Verwendung des Windows-Authentifizierungsmodus, dass das Gewähren einer nicht vertrauenswürdigen Benutzerberechtigung für die Verbindung mit msvsmon gefährlich ist, da dem Benutzer alle Ihre Berechtigungen auf dem Computer erteilt werden, auf dem msvsmon gehostet wird.

Debuggen Sie keinen unbekannten Prozess auf einem Remotecomputer: Es gibt potenzielle Exploits, die sich auf den Computer auswirken können, auf dem der Debugger ausgeführt wird oder msvsmon kompromittiert. Wenn Sie unbedingt einen unbekannten Prozess debuggen müssen, versuchen Sie, lokal zu debuggen, und verwenden Sie eine Firewall, um potenzielle Bedrohungen lokal zu lokalisieren.

Informationen zum Konfigurieren von msvsmon finden Sie unter Einrichten des Remotedebuggers.

Sicherheit beim Debuggen von Webdiensten

Es ist sicherer, lokal zu debuggen, da Visual Studio wahrscheinlich nicht auf dem Webserver installiert ist, ist das lokale Debuggen möglicherweise nicht praktisch. Im Allgemeinen erfolgt das Debuggen von Webdiensten remote, mit Ausnahme der Entwicklung, daher gelten die Empfehlungen für die Remotedebuggingsicherheit auch für das Debuggen von Webdiensten. Hier sind einige zusätzliche bewährte Methoden. Weitere Informationen finden Sie unter Debuggen von XML-Webdiensten.

• Aktivieren Sie das Debuggen nicht auf einem Webserver, der kompromittiert wurde.

• Stellen Sie sicher, dass der Webserver sicher ist, bevor Sie ihn debuggen. Wenn Sie nicht sicher sind, dass sie sicher ist, debuggen Sie sie nicht.

• Achten Sie besonders darauf, wenn Sie einen Webdienst debuggen, der im Internet verfügbar gemacht wird.

Externe Komponenten

Beachten Sie den Vertrauensstatus externer Komponenten, mit denen Ihr Programm interagiert, insbesondere, wenn Sie den Code nicht geschrieben haben. Beachten Sie außerdem Komponenten, die möglicherweise von Visual Studio oder dem Debugger verwendet werden.

Symbole und Quellcode

Zwei Visual Studio-Tools, bei denen Sie über Sicherheit nachdenken müssen, sind folgende:

• Source Server, der Ihnen Versionen von Quellcode aus einem Quellcode-Repository bereitstellt. Es ist nützlich, wenn Sie nicht über die aktuelle Version des Quellcodes eines Programms verfügen. Sicherheitswarnung: Debugger muss nicht vertrauenswürdigen Befehl ausführen.

• Symbolserver, der zum Bereitstellen der Symbole verwendet wird, die zum Debuggen eines Absturzes während eines Systemaufrufs erforderlich sind.

  Siehe Symbol (.pdb) und Quelldateien angeben

Verwandte Inhalte

• Debuggereinstellungen und -vorbereitung
• Erster Einblick in den Debugger
• Sicherheitswarnung: Das Anfügen an einen Prozess, der einem nicht vertrauenswürdigen Benutzer gehört, kann gefährlich sein. Falls die folgenden Informationen verdächtig erscheinen oder Sie unsicher sind, hängen Sie diese nicht an diesen Prozess an.
• Sicherheitswarnung: Debugger muss nicht vertrauenswürdigen Befehl ausführen