Zabezpieczenia debugera

Możliwość debugowania innego procesu zapewnia bardzo szerokie uprawnienia, których nie byłoby inaczej, zwłaszcza w przypadku zdalnego debugowania. Złośliwy debuger może wyrządzić powszechne szkody na debugowanej maszynie.

Jednak wielu deweloperów nie zdaje sobie sprawy, że zagrożenie bezpieczeństwa może również przepływać w przeciwnym kierunku. Istnieje możliwość, aby złośliwy kod w procesie debugowania zagroził bezpieczeństwu maszyny debugowania: istnieje wiele luk w zabezpieczeniach, które muszą być chronione.

Najlepsze praktyki w zakresie zabezpieczeń

Istnieje niejawna relacja zaufania między debugowaniem kodu a debugerem. Jeśli chcesz coś debugować, warto również uruchomić go. Najważniejsze jest to, że musisz mieć możliwość zaufania temu, co debugujesz. Jeśli nie możesz mu ufać, nie należy go debugować lub debugować go z komputera, na który można sobie pozwolić, aby zagrozić i w izolowanym środowisku.

Aby zmniejszyć potencjalną powierzchnię ataków, debugowanie powinno być wyłączone na maszynach produkcyjnych. Z tego samego powodu debugowanie nigdy nie powinno być włączone przez czas nieokreślony.

Zabezpieczenia zarządzanego debugowania

Poniżej przedstawiono kilka ogólnych zaleceń, które mają zastosowanie do wszystkich zarządzanych debugowania.

• Podczas dołączania do niezaufanego procesu użytkownika należy zachować ostrożność: jeśli to zrobisz, zakładasz, że jest godna zaufania. Podczas próby dołączenia do procesu niezaufanego użytkownika zostanie wyświetlone okno dialogowe ostrzeżenia o zabezpieczeniach z pytaniem, czy chcesz dołączyć do procesu. "Zaufani użytkownicy" obejmują Użytkownika oraz zestaw użytkowników standardowych, które są często zdefiniowane na komputerach z zainstalowanym programem .NET Framework, takimi jak aspnet, localsystem, networkservice i localservice. Aby uzyskać więcej informacji, zobacz Ostrzeżenie o zabezpieczeniach: dołączanie do procesu należącego do niezaufanego użytkownika może być niebezpieczne. Jeśli poniższe informacje wyglądają podejrzanie lub nie masz pewności, nie dołączaj do tego procesu.

• Podczas pobierania projektu z Internetu i ładowania go do programu Visual Studio należy zachować ostrożność. Jest to bardzo ryzykowne, aby zrobić nawet bez debugowania. Gdy to zrobisz, zakładasz, że projekt i kod, który zawiera, są wiarygodne.

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

Zabezpieczenia zdalnego debugowania

Debugowanie lokalne jest ogólnie bezpieczniejsze niż debugowanie zdalne. Debugowanie zdalne zwiększa całkowity obszar powierzchni, który można sondować.

Monitor zdalnego debugowania programu Visual Studio (msvsmon.exe) jest używany w debugowaniu zdalnym i istnieje kilka zaleceń dotyczących zabezpieczeń dotyczących jego konfigurowania. Preferowanym sposobem skonfigurowania trybu uwierzytelniania jest uwierzytelnianie systemu Windows, ponieważ tryb uwierzytelniania nie jest bezpieczny.

W przypadku korzystania z trybu uwierzytelniania systemu Windows należy pamiętać, że przyznanie niezaufanym użytkownikowi uprawnień do nawiązywania połączenia z msvsmon jest niebezpieczne, ponieważ użytkownik otrzymuje wszystkie uprawnienia na komputerze hostujący msvsmon.

Nie debuguj nieznanego procesu na maszynie zdalnej: istnieją potencjalne luki w zabezpieczeniach, które mogą mieć wpływ na maszynę z uruchomionym debugerem lub które mogą naruszyć bezpieczeństwo msvsmon. Jeśli absolutnie musisz debugować nieznany proces, spróbuj debugować lokalnie i użyć zapory, aby zachować wszelkie potencjalne zagrożenia zlokalizowane.

Aby uzyskać informacje na temat konfigurowania programu msvsmon, zobacz Konfigurowanie zdalnego debugera.

Zabezpieczenia debugowania usług internetowych

Bezpieczniej jest debugować lokalnie, ale ponieważ prawdopodobnie nie masz zainstalowanego programu Visual Studio na serwerze internetowym, lokalne debugowanie może nie być praktyczne. Ogólnie rzecz biorąc, debugowanie usług sieci Web odbywa się zdalnie, z wyjątkiem podczas programowania, więc zalecenia dotyczące zabezpieczeń debugowania zdalnego mają zastosowanie również do debugowania usług sieci Web. Oto kilka dodatkowych najlepszych rozwiązań. Aby uzyskać więcej informacji, zobacz Debugowanie usług sieci Web XML.

• Nie włączaj debugowania na serwerze sieci Web, który został naruszony.

• Przed debugowaniem upewnij się, że serwer sieci Web jest bezpieczny. Jeśli nie masz pewności, że jest on bezpieczny, nie debuguj go.

• Należy zachować szczególną ostrożność, jeśli debugujesz usługę internetową, która jest uwidoczniona w Internecie.

Składniki zewnętrzne

Należy pamiętać o stanie zaufania składników zewnętrznych, z którymi współpracuje program, zwłaszcza jeśli nie zapisano kodu. Należy również pamiętać o składnikach, których może używać program Visual Studio lub debuger.

Symbole i kod źródłowy

Dwa narzędzia programu Visual Studio, które wymagają myślenia o zabezpieczeniach, są następujące:

• Serwer źródłowy, który udostępnia wersje kodu źródłowego z repozytorium kodu źródłowego. Jest to przydatne, gdy nie masz bieżącej wersji kodu źródłowego programu. Ostrzeżenie o zabezpieczeniach: Debuger musi wykonać niezaufane polecenie.

• Serwer symboli, który służy do dostarczania symboli potrzebnych do debugowania awarii podczas wywołania systemu.

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

Powiązana zawartość

• Ustawienia debugera i przygotowanie
• Pierwsze spojrzenie na debugera
• Ostrzeżenie o zabezpieczeniach: dołączanie do procesu należącego do niezaufanego użytkownika może być niebezpieczne. Jeśli informacje wyglądają podejrzanie lub nie masz do nich pełnego zaufania, nie dołączaj do tego procesu
• Ostrzeżenie o zabezpieczeniach: debuger musi wykonać polecenie niezaufane