Delen via

Beveiligingsproblemen in reflectie-emit

  • Artikel

.NET Framework biedt drie manieren om algemene tussenliggende taal (CIL) te verzenden, elk met een eigen beveiligingsproblemen:

Ongeacht de manier waarop u dynamische code genereert, vereist het uitvoeren van de gegenereerde code alle machtigingen die zijn vereist voor de typen en methoden die door de gegenereerde code worden gebruikt.

Notitie

De machtigingen die nodig zijn voor het weergeven van code en het verzenden van code, zijn gewijzigd met voltooiende releases van .NET Framework. Zie versie-informatie verderop in dit artikel.

Dynamische assembly's

Dynamische assembly's worden gemaakt met behulp van overbelastingen van de AppDomain.DefineDynamicAssembly methode. De meeste overbelastingen van deze methode worden afgeschaft in .NET Framework 4 vanwege het verwijderen van het beveiligingsbeleid voor de hele machine. De resterende overbelastingen kunnen door elke code worden uitgevoerd, ongeacht het vertrouwensniveau. Deze overbelastingen vallen in twee groepen: die een lijst met kenmerken opgeven die moeten worden toegepast op de dynamische assembly wanneer deze wordt gemaakt en die niet. Als u het transparantiemodel voor de assembly niet opgeeft door het SecurityRulesAttribute kenmerk toe te passen wanneer u het maakt, wordt het transparantiemodel overgenomen van de verzendende assembly.

Notitie

Kenmerken die u toepast op de dynamische assembly nadat deze is gemaakt, met behulp van de SetCustomAttribute methode, worden pas van kracht nadat de assembly op de schijf is opgeslagen en opnieuw in het geheugen is geladen.

Code in een dynamische assembly heeft toegang tot zichtbare typen en leden in andere assembly's.

Notitie

Dynamische assembly's maken geen gebruik van de ReflectionPermissionFlag.MemberAccess en ReflectionPermissionFlag.RestrictedMemberAccess vlaggen waarmee dynamische methoden toegang hebben tot niet-openbare typen en leden.

Tijdelijke dynamische assembly's worden gemaakt in het geheugen en worden nooit opgeslagen op schijf, zodat ze geen machtigingen voor bestandstoegang nodig hebben. Voor het opslaan van een dynamische assembly op schijf zijn de juiste vlaggen vereist FileIOPermission .

Dynamische assembly's genereren op basis van gedeeltelijk vertrouwde code

Houd rekening met de voorwaarden waarin een assembly met internetmachtigingen een tijdelijke dynamische assembly kan genereren en de bijbehorende code kan uitvoeren:

  • De dynamische assembly maakt alleen gebruik van openbare typen en leden van andere assembly's.

  • De machtigingen die door deze typen en leden worden gevraagd, worden opgenomen in de toekenningsset van de gedeeltelijk vertrouwde assembly.

  • De assembly wordt niet opgeslagen op schijf.

  • Foutopsporingssymbolen worden niet gegenereerd. (Internet en LocalIntranet machtigingensets bevatten niet de benodigde machtigingen.)

Anoniem gehoste dynamische methoden

Anoniem gehoste dynamische methoden worden gemaakt met behulp van de twee DynamicMethod constructors die geen gekoppeld type of module opgeven, DynamicMethod(String, Type, Type[]) en DynamicMethod(String, Type, Type[], Boolean). Deze constructors plaatsen de dynamische methoden in een door het systeem geleverde, volledig vertrouwde, beveiligingstransparante assembly. Er zijn geen machtigingen vereist voor het gebruik van deze constructors of voor het verzenden van code voor de dynamische methoden.

Wanneer er een anoniem gehoste dynamische methode wordt gemaakt, wordt de aanroepstack vastgelegd. Wanneer de methode is samengesteld, worden er beveiligingsvereisten gesteld op basis van de vastgelegde aanroepstack.

Notitie

Conceptueel worden eisen gesteld tijdens de bouw van de methode. Dat wil gezegd, er kunnen eisen worden gesteld wanneer elke CIL-instructie wordt verzonden. In de huidige implementatie worden alle eisen gesteld wanneer de DynamicMethod.CreateDelegate methode wordt aangeroepen of wanneer de Just-In-Time-compiler (JIT) wordt aangeroepen, als de methode wordt aangeroepen zonder aan te roepen CreateDelegate.

Als het toepassingsdomein dit toestaat, kunnen anoniem gehoste dynamische methoden JIT-zichtbaarheidscontroles overslaan, afhankelijk van de volgende beperking: De niet-openbare typen en leden die worden geopend door een anoniem gehoste dynamische methode moeten zich in assembly's bevinden waarvan de toekenningssets gelijk zijn aan, of subsets van, de toekenningsset van de verzendende aanroepstack. Deze beperkte mogelijkheid om JIT-zichtbaarheidscontroles over te slaan, wordt ingeschakeld als het toepassingsdomein met de ReflectionPermissionFlag.RestrictedMemberAccess vlag verleentReflectionPermission.

  • Als uw methode alleen openbare typen en leden gebruikt, zijn er geen machtigingen vereist tijdens de bouw.

  • Als u opgeeft dat JIT-zichtbaarheidscontroles moeten worden overgeslagen, bevat de vraag die wordt gemaakt wanneer de methode wordt samengesteld, de ReflectionPermissionReflectionPermissionFlag.RestrictedMemberAccess vlag en de toekenningsset van de assembly die het niet-openbare lid bevat dat wordt geopend.

Omdat rekening wordt gehouden met de toekenningsset van het niet-openbare lid, kan gedeeltelijk vertrouwde code die is verleend ReflectionPermissionFlag.RestrictedMemberAccess , de bevoegdheden ervan niet verhogen door niet-openbare leden van vertrouwde assembly's uit te voeren.

Net als bij elke andere verzonden code vereist het uitvoeren van de dynamische methode alle machtigingen die worden vereist door de methoden die door de dynamische methode worden gebruikt.

De systeemassembly die als host fungeert voor anoniem gehoste dynamische methoden, maakt gebruik van het SecurityRuleSet.Level1 transparantiemodel, het transparantiemodel dat werd gebruikt in .NET Framework vóór .NET Framework 4.

Zie de DynamicMethod klas voor meer informatie.

Anoniem gehoste dynamische methoden genereren van gedeeltelijk vertrouwde code

Houd rekening met de voorwaarden waarin een assembly met internetmachtigingen een anoniem gehoste dynamische methode kan genereren en deze kan uitvoeren:

  • De dynamische methode maakt alleen gebruik van openbare typen en leden. Als de toekenningsset bevat ReflectionPermissionFlag.RestrictedMemberAccess, kan deze niet-openbare typen en leden van een assembly gebruiken waarvan de subsidieset gelijk is aan, of een subset van, de toekenningsset van de verzendende assembly.

  • De machtigingen die vereist zijn voor alle typen en leden die door de dynamische methode worden gebruikt, worden opgenomen in de toekenningsset van de gedeeltelijk vertrouwde assembly.

Notitie

Dynamische methoden bieden geen ondersteuning voor foutopsporingssymbolen.

Dynamische methoden die zijn gekoppeld aan bestaande assembly's

Als u een dynamische methode wilt koppelen aan een type of module in een bestaande assembly, gebruikt u een van de DynamicMethod constructors die het bijbehorende type of de bijbehorende module opgeven. De machtigingen die nodig zijn om deze constructors aan te roepen, variëren, omdat het koppelen van een dynamische methode aan een bestaand type of een bestaande module de dynamische methode toegang geeft tot niet-openbare typen en leden:

  • Een dynamische methode die aan een type is gekoppeld, heeft toegang tot alle leden van dat type, zelfs privéleden, en tot alle interne typen en leden in de assembly die het bijbehorende type bevat.

  • Een dynamische methode die aan een module is gekoppeld, heeft toegang tot alle internal typen en leden (Friend in Visual Basic, assembly in metagegevens van algemene taalruntime) in de module.

Daarnaast kunt u een constructor gebruiken die de mogelijkheid aangeeft om de zichtbaarheidscontroles van de JIT-compiler over te slaan. Dit geeft uw dynamische methode toegang tot alle typen en leden in alle assembly's, ongeacht het toegangsniveau.

De machtigingen die door de constructor worden gevraagd, zijn afhankelijk van hoeveel toegang u besluit om uw dynamische methode te geven:

Hoewel de items in deze lijst worden beschreven in termen van de toekenningsset van de verzendende assembly, moet u er rekening mee houden dat de eisen worden gesteld aan de volledige aanroepstack, inclusief de grens van het toepassingsdomein.

Zie de DynamicMethod klas voor meer informatie.

Dynamische methoden genereren op basis van gedeeltelijk vertrouwde code

Notitie

De aanbevolen manier om dynamische methoden te genereren op basis van gedeeltelijk vertrouwde code, is door anoniem gehoste dynamische methoden te gebruiken.

Houd rekening met de voorwaarden waarin een assembly met internetmachtigingen een dynamische methode kan genereren en deze kan uitvoeren:

  • De dynamische methode is gekoppeld aan de module of het type dat deze verzendt, of de toekenningsset bevat ReflectionPermissionFlag.RestrictedMemberAccess en is gekoppeld aan een module in een assembly waarvan de toekenningsset gelijk is aan, of een subset van de toekenningsset van de verzendende assembly.

  • De dynamische methode maakt alleen gebruik van openbare typen en leden. Als de toekenningsset bevat ReflectionPermissionFlag.RestrictedMemberAccess en is gekoppeld aan een module in een assembly waarvan de toekenningsset gelijk is aan of een subset van de verlenende assembly, kan deze typen en leden gebruiken die zijn gemarkeerd internal (Friend in Visual Basic, assembly in algemene metagegevens van runtime voor taal) in de bijbehorende module.

  • De machtigingen die worden gevraagd door alle typen en leden die door de dynamische methode worden gebruikt, worden opgenomen in de toekenningsset van de gedeeltelijk vertrouwde assembly.

  • Met de dynamische methode worden JIT-zichtbaarheidscontroles niet overgeslagen.

Notitie

Dynamische methoden bieden geen ondersteuning voor foutopsporingssymbolen.

Versie-informatie

Vanaf .NET Framework 4 wordt het beveiligingsbeleid voor de hele machine geëlimineerd en wordt de beveiligingstransparantie het standaardmechanisme voor afdwinging.

Vanaf .NET Framework 2.0 Service Pack 1 is ReflectionPermission de ReflectionPermissionFlag.ReflectionEmit vlag niet meer vereist bij het verzenden van dynamische assembly's en dynamische methoden. Deze vlag is vereist in alle eerdere versies van .NET Framework.

Notitie

ReflectionPermission met de ReflectionPermissionFlag.ReflectionEmit vlag is standaard opgenomen in de FullTrust en LocalIntranet benoemde machtigingensets, maar niet in de Internet machtigingenset. Daarom kan in eerdere versies van .NET Framework een bibliotheek alleen worden gebruikt met internetmachtigingen als er een Assert voor ReflectionEmitwordt uitgevoerd. Voor dergelijke bibliotheken is zorgvuldige beveiligingsbeoordeling vereist, omdat coderingsfouten kunnen leiden tot beveiligingsgaten. Met .NET Framework 2.0 SP1 kan code worden verzonden in gedeeltelijke vertrouwensscenario's zonder dat er beveiligingsvereisten worden gesteld, omdat het genereren van code niet inherent een bevoegde bewerking is. Dat wil gezegd, de gegenereerde code heeft niet meer machtigingen dan de assembly die deze verzendt. Hierdoor kunnen bibliotheken die code verzenden, transparant zijn en wordt de noodzaak om te bevestigen ReflectionEmitverwijderd, waardoor de taak van het schrijven van een beveiligde bibliotheek wordt vereenvoudigd.

Daarnaast introduceert .NET Framework 2.0 SP1 de ReflectionPermissionFlag.RestrictedMemberAccess vlag voor toegang tot niet-openbare typen en leden van gedeeltelijk vertrouwde dynamische methoden. In eerdere versies van .NET Framework is de ReflectionPermissionFlag.MemberAccess vlag vereist voor dynamische methoden die toegang hebben tot niet-openbare typen en leden. Dit is een machtiging die nooit mag worden verleend aan gedeeltelijk vertrouwde code.

Ten slotte introduceert .NET Framework 2.0 SP1 anoniem gehoste methoden.

Informatie verkrijgen over typen en leden

Vanaf .NET Framework 2.0 zijn er geen machtigingen vereist voor het verkrijgen van informatie over niet-openbare typen en leden. Weerspiegeling wordt gebruikt om informatie te verkrijgen die nodig is voor het verzenden van dynamische methoden. Objecten worden bijvoorbeeld MethodInfo gebruikt om methode-aanroepen te verzenden. Voor eerdere versies van .NET Framework is de ReflectionPermissionFlag.TypeInformation vlag vereistReflectionPermission. Zie Beveiligingsoverwegingen voor reflectie voor meer informatie.

Zie ook