Riktlinjer för säker kodning

  • Artikel

De flesta programkoder kan helt enkelt använda infrastrukturen som implementeras av .NET. I vissa fall krävs ytterligare programspecifik säkerhet, antingen genom att utöka säkerhetssystemet eller med hjälp av nya ad hoc-metoder.

Med hjälp av .NET-framtvingade behörigheter och annan tillämpning i din kod bör du upprätta hinder för att förhindra skadlig kod från att komma åt information som du inte vill att den ska ha eller utföra andra oönskade åtgärder. Dessutom måste du hitta en balans mellan säkerhet och användbarhet i alla förväntade scenarier med hjälp av betrodd kod.

Den här översikten beskriver de olika sätt som kod kan utformas för att fungera med säkerhetssystemet.

Skydda resursåtkomst

När du utformar och skriver koden måste du skydda och begränsa den åtkomst som koden har till resurser, särskilt när du använder eller anropar kod av okänt ursprung. Tänk på följande tekniker för att se till att koden är säker:

  • Använd inte Code Access Security (CAS).

  • Använd inte delvis betrodd kod.

  • Använd inte attributet AllowPartiallyTrustedCaller (APTCA).

  • Använd inte .NET-fjärrkommunikation.

  • Använd inte DCOM (Distributed Component Object Model).

  • Använd inte binära formaterare.

Kodåtkomstsäkerhet och säkerhetstransparent kod stöds inte som en säkerhetsgräns med delvis betrodd kod. Vi avråder från att läsa in och köra kod av okänt ursprung utan att införa alternativa säkerhetsåtgärder. De alternativa säkerhetsåtgärderna är:

  • Virtualisering

  • AppContainers

  • Operativsystemanvändare och behörigheter

  • Hyper-V-containrar

Säkerhetsneutral kod

Säkerhetsneutral kod gör inget explicit med säkerhetssystemet. Den körs med de behörigheter som den får. Även om program som inte kan fånga upp säkerhetsundantag som är associerade med skyddade åtgärder (till exempel att använda filer, nätverk och så vidare) kan resultera i ett ohanterat undantag, drar säkerhetsneutral kod fortfarande nytta av säkerhetsteknikerna i .NET.

Ett säkerhetsneutralt bibliotek har särskilda egenskaper som du bör förstå. Anta att biblioteket innehåller API-element som använder filer eller anropar ohanterad kod. Om koden inte har motsvarande behörighet körs den inte enligt beskrivningen. Men även om koden har behörigheten måste all programkod som anropar den ha samma behörighet för att fungera. Om den anropande koden inte har rätt behörighet visas en SecurityException som ett resultat av kodåtkomstens säkerhetsstack.

Programkod som inte är en återanvändbar komponent

Om koden är en del av ett program som inte anropas av annan kod är säkerheten enkel och särskild kodning kanske inte krävs. Kom dock ihåg att skadlig kod kan anropa din kod. Även om kodåtkomstsäkerhet kan hindra skadlig kod från att komma åt resurser, kan sådan kod fortfarande läsa värden för dina fält eller egenskaper som kan innehålla känslig information.

Om koden accepterar användarindata från Internet eller andra otillförlitliga källor måste du dessutom vara försiktig med skadliga indata.

Hanterad omslutning till intern kodimplementering

I det här scenariot implementeras vanligtvis några användbara funktioner i inbyggd kod som du vill göra tillgängliga för hanterad kod. Hanterade omslutningar är enkla att skriva med antingen plattformsanrop eller COM-interop. Men om du gör det måste de som anropar omslutningen ha ohanterade kodrättigheter för att lyckas. Enligt standardprincipen innebär det att kod som laddas ned från ett intranät eller Internet inte fungerar med omslutarna.

I stället för att ge ohanterade kodrättigheter till alla program som använder dessa omslutningar är det bättre att endast ge dessa rättigheter till omslutningskoden. Om den underliggande funktionen inte exponerar några resurser och implementeringen på samma sätt är säker behöver omslutningen endast hävda sina rättigheter, vilket gör att all kod kan anropa den. När resurser ingår bör säkerhetskodning vara samma som det bibliotekskodfall som beskrivs i nästa avsnitt. Eftersom omslutningen potentiellt exponerar anropare för dessa resurser är noggrann verifiering av säkerheten för den interna koden nödvändig och är omslutningens ansvar.

Bibliotekskod som exponerar skyddade resurser

Följande metod är den mest kraftfulla och därmed potentiellt farliga (om den görs felaktigt) för säkerhetskodning: biblioteket fungerar som ett gränssnitt för annan kod för åtkomst till vissa resurser som annars inte är tillgängliga, precis som .NET-klasserna tillämpar behörigheter för de resurser de använder. Var du än exponerar en resurs måste koden först kräva den behörighet som är lämplig för resursen (dvs. den måste utföra en säkerhetskontroll) och sedan vanligtvis hävda sina rättigheter att utföra den faktiska åtgärden.

Se även