Udostępnij za pośrednictwem


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.

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.

Error dialog

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: