Delen via

Richtlijnen voor veilig coderen

  • Artikel

De meeste toepassingscode kan gewoon gebruikmaken van de infrastructuur die door .NET is geïmplementeerd. In sommige gevallen is aanvullende toepassingsspecifieke beveiliging vereist, gebouwd door het beveiligingssysteem uit te breiden of door nieuwe ad-hocmethoden te gebruiken.

Met behulp van afgedwongen .NET-machtigingen en andere afdwinging in uw code moet u obstakels opzetten om te voorkomen dat schadelijke code toegang krijgt tot informatie die u niet wilt hebben of andere ongewenste acties wilt uitvoeren. Daarnaast moet u een evenwicht vinden tussen beveiliging en bruikbaarheid in alle verwachte scenario's met behulp van vertrouwde code.

In dit overzicht worden de verschillende manieren beschreven waarop code kan worden ontworpen voor gebruik met het beveiligingssysteem.

Toegang tot resources beveiligen

Bij het ontwerpen en schrijven van uw code moet u de toegang tot die code beveiligen en beperken tot resources, met name wanneer u code van onbekende oorsprong gebruikt of aanroept. Houd dus rekening met de volgende technieken om ervoor te zorgen dat uw code veilig is:

  • Gebruik geen CAS (Code Access Security).

  • Gebruik geen gedeeltelijke vertrouwde code.

  • Gebruik het kenmerk AllowPartiallyTrustedCaller (APTCA) niet.

  • Gebruik geen externe communicatie van .NET.

  • Gebruik geen DCOM (Distributed Component Object Model).

  • Gebruik geen binaire formatters.

Codetoegangsbeveiliging en beveiligingstransparante code worden niet ondersteund als een beveiligingsgrens met gedeeltelijk vertrouwde code. We raden u aan om code van onbekende oorsprongen te laden en uit te voeren zonder alternatieve beveiligingsmaatregelen in te stellen. De alternatieve beveiligingsmaatregelen zijn:

  • Virtualisatie

  • AppContainers

  • Gebruikers en machtigingen van het besturingssysteem

  • Hyper-V-containers

Beveiligingsneutrale code

Beveiligingsneutrale code doet niets expliciet met het beveiligingssysteem. Het wordt uitgevoerd met de machtigingen die het ontvangt. Hoewel toepassingen die geen beveiligingsuitzonderingen kunnen ondervangen die zijn gekoppeld aan beveiligde bewerkingen (zoals het gebruik van bestanden, netwerken enzovoort), kunnen leiden tot een onverwerkte uitzondering, maakt beveiligingneutrale code nog steeds gebruik van de beveiligingstechnologieën in .NET.

Een beveiligingsneutrale bibliotheek heeft speciale kenmerken die u moet begrijpen. Stel dat uw bibliotheek API-elementen bevat die gebruikmaken van bestanden of onbeheerde code aanroepen. Als uw code niet over de bijbehorende machtiging beschikt, wordt deze niet uitgevoerd zoals beschreven. Zelfs als de code de machtiging heeft, moet elke toepassingscode die deze aanroept, dezelfde machtiging hebben om te kunnen werken. Als de aanroepende code niet over de juiste machtiging beschikt, wordt er een SecurityException weergegeven als gevolg van de beveiligingsstack voor codetoegang.

Toepassingscode die geen herbruikbaar onderdeel is

Als uw code deel uitmaakt van een toepassing die niet door andere code wordt aangeroepen, is beveiliging eenvoudig en is speciale codering mogelijk niet vereist. Vergeet echter niet dat schadelijke code uw code kan aanroepen. Hoewel de beveiliging van codetoegang kan verhinderen dat schadelijke code toegang heeft tot resources, kan deze code nog steeds waarden lezen van uw velden of eigenschappen die gevoelige informatie kunnen bevatten.

Als uw code gebruikersinvoer van internet of andere onbetrouwbare bronnen accepteert, moet u voorzichtig zijn met schadelijke invoer.

Beheerde wrapper naar systeemeigen code-implementatie

Normaal gesproken wordt in dit scenario enkele nuttige functionaliteit geïmplementeerd in systeemeigen code die u beschikbaar wilt maken voor beheerde code. Beheerde wrappers zijn eenvoudig te schrijven met behulp van platform-aanroepen of COM-interop. Als u dit echter doet, moeten aanroepers van uw wrappers onbeheerde coderechten hebben om te kunnen slagen. Onder standaardbeleid betekent dit dat code die is gedownload van een intranet of internet niet werkt met de wrappers.

In plaats van onbeheerde coderechten te geven aan alle toepassingen die deze wrappers gebruiken, is het beter om deze rechten alleen aan de wrapper-code te geven. Als de onderliggende functionaliteit geen resources beschikbaar maakt en de implementatie eveneens veilig is, hoeft de wrapper alleen zijn rechten te bevestigen, waardoor code kan worden aangeroepen. Wanneer resources betrokken zijn, moet beveiligingscodering hetzelfde zijn als de codecase van de bibliotheek die in de volgende sectie wordt beschreven. Omdat de wrapper mogelijk bellers beschikbaar maakt voor deze resources, is zorgvuldige verificatie van de veiligheid van de systeemeigen code nodig en is de verantwoordelijkheid van de wrapper.

Bibliotheekcode die beveiligde resources beschikbaar maakt

De volgende aanpak is de krachtigste en mogelijk gevaarlijkste (indien onjuist gedaan) voor beveiligingscodering: uw bibliotheek fungeert als een interface voor andere code voor toegang tot bepaalde resources die niet anders beschikbaar zijn, net zoals de .NET-klassen machtigingen afdwingen voor de resources die ze gebruiken. Waar u een resource beschikbaar maakt, moet uw code eerst de machtiging eisen die geschikt is voor de resource (dat wil zeggen dat er een beveiligingscontrole moet worden uitgevoerd) en vervolgens de rechten ervan bevestigen om de werkelijke bewerking uit te voeren.

Zie ook