Zabezpieczenia debugera

Artykuł
06/10/2015

Możliwość debugowania inny proces zapewnia bardzo szeroki uprawnień, które nie w przeciwnym razie będzie, zwłaszcza wówczas, gdy zdalnego debugowania.Złośliwego debuger może spowodować uszkodzenie powszechnie stosowanych na komputerze jest debugowane.

Jednak wielu deweloperów nie pamiętać, że zagrożeniem dla bezpieczeństwa może również przechodzić w przeciwnym kierunku.Istnieje możliwość złośliwego kodu w proces obiekt debugowany zagrozić bezpieczeństwa maszynę debugowania: liczbę zabezpieczeniach, które musi być zabezpieczona przed.

Najlepsze praktyki w zakresie zabezpieczeń

Ma relacji zaufania niejawnych między kod, który debugowania i debuger.Jeśli użytkownik jest gotowa do debugowania coś, należy także wolę ją uruchomić.Dolna linia jest, że użytkownik musi mieć możliwość zaufania są debugowania.Jeśli nie ufasz, następnie użytkownik powinien nie go zdebugować lub należy go zdebugować z komputera, na którym można zapewnić, aby zagrozić, a w środowisku izolowanym.

Aby zmniejszyć potencjalne ataku, debugowanie powinno zostać wyłączone na komputerach produkcyjnych.Z tego samego powodu debugowanie powinno nigdy nie można włączyć nieskończoność.

Zarządzane debugowania zabezpieczeń

Poniżej przedstawiono ogólne zalecenia mające zastosowanie do wszystkich zarządzanych debugowania.

Należy zachować ostrożność podczas dołączania do procesu niezaufany użytkownik: po wykonaniu, możesz założyć jest zaufane.Podczas próby dołączenia do procesu niezaufany użytkownik, zabezpieczenia ostrzeżenie okno dialogowe potwierdzenia pojawi zapytaniem, czy chcesz dołączyć do procesu. "Zaufane użytkowników"można uwzględnić, a zestaw standardowych użytkowników często zdefiniowane na maszynach, które mają środowiska .NET Framework, takich jak aspnet, localsystem, Usługa sieciowa, i Usługa lokalna.Aby uzyskać więcej informacji, zobacz Ostrzeżenie o zabezpieczeniach: Dołączanie do procesu niezaufanego użytkownika może być niebezpieczne. Jeżeli następujące informacje wydają się podejrzane lub niepewne, nie należy podłączać się do procesu..
Należy zachować ostrożność podczas pobierania projektu wyłączenia z Internetu i ładuje ją do Visual Studio.Jest to bardzo ryzykowne przeprowadzić nawet bez debugowania.Gdy to zrobisz, są przy założeniu projektu i kodu, który zawiera są godne zaufania.

Aby uzyskać więcej informacji, zobacz Debugowanie zarządzanego kodu.

Zdalnego debugowania zabezpieczeń

Debugowanie lokalnego jest zazwyczaj bezpieczniejsze niż zdalnego debugowania.Zdalne debugowanie zwiększa całkowitej powierzchni, który może być sondowany.

Visual Studio zdalnego debugowania Monitor (msvsmon.exe) jest używany podczas zdalnego debugowania i istnieje kilka zaleceń zabezpieczeń do konfigurowania go.Preferowany sposób, aby skonfigurować tryb uwierzytelniania jest uwierzytelnianie systemu Windows, ponieważ tryb uwierzytelniania nie jest niebezpieczne.

Okno dialogowe błędu

Podczas korzystania z trybu uwierzytelniania systemu Windows, należy pamiętać, że przyznawania uprawnień niezaufany użytkownik, aby nawiązać połączenie msvsmon jest niebezpieczne, ponieważ użytkownik otrzymuje Twoje uprawnienia na komputerze...

Nie debugowanie nieznany procesu na komputerze zdalnym: istnieją potencjalne oprogramowanie, które mogą mieć wpływ na komputerze, na którym debuger lub które mogłyby naruszyć msvsmon.exe, programu Visual Studio zdalnego debugowania monitora.Jeśli można całkowicie debugować nieznany proces, spróbuj debugowanie lokalnie i korzystanie z zapory, aby zachować wszelkie potencjalnymi zagrożeniami zlokalizowany.

Aby uzyskać więcej informacji, zobacz Zdalne debugowanie i diagnostyka.

Debugowanie zabezpieczeń usługi sieci Web

Jest bezpieczniejsze do debugowania lokalnie, ale od tego czasu prawdopodobnie nie masz Visual Studio zainstalowane na serwerze sieci web, debugowanie lokalny może nie być praktyczne.Ogólnie rzecz biorąc debugowania usługi sieci Web jest wykonywane zdalnie, z wyjątkiem podczas tworzenia aplikacji, więc zalecenia dla zdalnego debugowania zabezpieczeń odnoszą się również do debugowania usługi sieci Web.Oto kilka dodatkowych najlepszych rozwiązań.Aby uzyskać więcej informacji, zobacz Debugging XML Web Services.

Unikanie włączania debugowania na serwerze sieci Web, którą przejął.
Upewnij się, że masz pewność, że serwer sieci Web są bezpieczne, przed jej debugowanie.Jeśli nie masz pewności, że jest bezpieczne, nie go zdebugować.
Należy zachować szczególną ostrożność, jeśli debugowania usługi sieci Web, który jest dostępny w Internecie.

Składniki zewnętrzne

Należy pamiętać o stanu zaufania składniki zewnętrzne, które program współdziała z, zwłaszcza, jeśli nie pisania kodu.Również znać składniki który Visual Studio lub debuger może użyć.

Symbole i kod źródłowy

Dwa Visual Studio narzędzi, które wymagają zastanawiać zabezpieczeń są następujące:

Źródło serwera, który zapewnia wersji kodu źródłowego z repozytorium kodu źródłowego.Jest przydatna, jeśli nie masz bieżącej wersji programu kodu źródłowego.Ostrzeżenie o zabezpieczeniach: Debuger musi wykonać niezaufaną komendę.
Symbol serwera, który jest używany do dostarczania symbole niezbędne do debugowania do awarii podczas połączenia z systemu.

Zobacz Określanie plików symboli (.pdb) i plików źródłowych w debugerze programu Visual Studio.