Felsökningssäkerhet

Möjligheten att felsöka en annan process ger dig mycket breda krafter som du annars inte skulle ha, särskilt när du felsöker på distans. Ett skadligt felsökningsprogram kan orsaka omfattande skador på den dator som debuggas.

Många utvecklare inser dock inte att säkerhetshotet också kan flöda i motsatt riktning. Det är möjligt att skadlig kod i processen som felsöks kan äventyra säkerheten för datorn som används för felsökning: det finns ett antal säkerhetsintrång som behöver skyddas från.

Metodtips för säkerhet

Det finns en implicit förtroenderelation mellan den kod som du felsöker och felsökningsprogrammet. Om du är villig att felsöka något bör du också vara villig att köra det. Slutsatsen är att du måste kunna lita på det du felsöker. Om du inte kan lita på det bör du inte felsöka det, eller så bör du felsöka det från en dator som du har råd att äventyra och i en isolerad miljö.

För att minska den potentiella attackytan bör felsökning inaktiveras på produktionsdatorer. Av samma anledning bör felsökning aldrig aktiveras på obestämd tid.

Hanterad felsökningssäkerhet

Här följer några allmänna rekommendationer som gäller för all hanterad felsökning.

• Var försiktig när du ansluter till en obetrodd användares process: när du gör det antar du att den är tillförlitlig. När du försöker ansluta till en obetrodd användares process visas en dialogruta för säkerhetsvarning som frågar om du vill koppla till processen. "Betrodda användare" inkluderar dig och en uppsättning standardanvändare som vanligtvis definieras på datorer som har .NET Framework installerat, till exempel aspnet, localsystem, networkservice och localservice. Mer information finns i Säkerhetsvarning: Det kan vara farligt att ansluta till en process som ägs av en ej betrodd användare. Om följande information ser misstänkt ut eller om du är osäker ska du inte ansluta till den här processen.

• Var försiktig när du laddar ned ett projekt från Internet och läser in det i Visual Studio. Detta är mycket riskabelt att göra även utan felsökning. När du gör detta antar du att projektet och koden som det innehåller är tillförlitliga.

  Mer information finns i Felsöka hanterad kod.

Fjärrfelsökningssäkerhet

Lokal felsökning är vanligtvis säkrare än fjärrfelsökning. Fjärrdebuggning ökar den totala ytan som kan undersökas.

Visual Studio Remote Debugging Monitor (msvsmon.exe) används vid fjärrfelsökning och det finns flera säkerhetsrekommendationer för att konfigurera den. Det bästa sättet att konfigurera autentiseringsläget är Windows-autentisering eftersom inget autentiseringsläge är osäkert.

När du använder Windows-autentiseringsläge bör du vara medveten om att det är farligt att bevilja en obetrodd användare behörighet att ansluta till msvsmon, eftersom användaren beviljas alla dina behörigheter på den dator som är värd för msvsmon.

Felsök inte en okänd process på en fjärrdator: det finns potentiella kryphål som kan påverka datorn som kör felsökningsprogrammet, eller som kan äventyra msvsmon. Om du absolut måste felsöka en okänd process kan du prova att felsöka lokalt och använda en brandvägg för att hålla eventuella hot lokaliserade.

Information om hur du konfigurerar msvsmon finns i Konfigurera fjärrfelsökaren.

Webbtjänstfelsökningssäkerhet

Det är säkrare att felsöka lokalt, men eftersom du förmodligen inte har Visual Studio installerat på webbservern kanske lokal felsökning inte är praktiskt. I allmänhet utförs felsökning av webbtjänster via fjärranslutning, förutom under utveckling, så rekommendationerna för fjärrfelsökningssäkerhet gäller även för felsökning av webbtjänster. Här följer några ytterligare metodtips. Mer information finns i Felsöka XML-webbtjänster.

• Aktivera inte felsökning på en webbserver som har komprometterats.

• Kontrollera att webbservern är säker innan du felsöker den. Om du inte är säker på att den är säker ska du inte felsöka den.

• Var särskilt försiktig om du felsöker en webbtjänst som är tillgänglig på Internet.

Externa komponenter

Tänk på förtroendestatusen för externa komponenter som ditt program interagerar med, särskilt om du inte skrev koden. Tänk också på komponenter som Visual Studio eller felsökningsprogrammet kan använda.

Symboler och källkod

Två Visual Studio-verktyg som kräver att du tänker på säkerhet är följande:

• Källserver, som ger dig versioner av källkod från en källkodslagringsplats. Det är användbart när du inte har den aktuella versionen av ett programs källkod. Säkerhetsvarning: Felsökningsprogrammet måste köra ett kommando som inte är betrott.

• Symbolserver, som används för att ange de symboler som behövs för att felsöka en krasch under ett systemanrop.

  Se Ange symbol (.pdb) och källfiler

Relaterat innehåll

• Inställningar för felsökning och förberedelse
• En första titt på felsökningsprogrammet
• Säkerhetsvarning: Det kan vara farligt att ansluta till en process som ägs av en ej betrodd användare. Om följande information ser misstänkt ut eller om du är osäker ska du inte ansluta till den här processen
• Säkerhetsvarning: Felsökningsprogrammet måste köra ett kommando som inte är betrott