Säkerhetsproblem i Reflection Emission

.NET Framework tillhandahåller tre sätt att generera ett gemensamt mellanliggande språk (CIL), var och en med sina egna säkerhetsproblem:

Oavsett hur du genererar dynamisk kod kräver körning av den genererade koden alla behörigheter som krävs av de typer och metoder som den genererade koden använder.

Anmärkning

De behörigheter som krävs för att reflektera över kod och generera kod har ändrats med efterföljande versioner av .NET Framework. Se Versionsinformation senare i den här artikeln.

Dynamiska sammansättningar

Dynamiska sammansättningar skapas med hjälp av överlagringar av AppDomain.DefineDynamicAssembly metoden. De flesta överlagringar av den här metoden är inaktuella i .NET Framework 4 på grund av att säkerhetsprincipen för hela datorn har eliminerats. De återstående överlagringarna kan köras av valfri kod, oavsett förtroendenivå. Dessa överlagringar hamnar i två grupper: de som anger en lista med attribut som ska tillämpas på den dynamiska sammansättningen när den skapas och de som inte gör det. Om du inte anger transparensmodellen för sammansättningen genom att tillämpa SecurityRulesAttribute-attributet när du skapar den, ärvs transparensmodellen från den emitterande sammansättningen.

Anmärkning

Attributen som du applicerar på den dynamiska sammansättningen efter att den har skapats med hjälp av SetCustomAttribute-metoden träder inte i kraft förrän sammansättningen har sparats till disk och lästs in i minnet igen.

Kod i en dynamisk sammansättning kan komma åt synliga typer och medlemmar i andra sammansättningar.

Anmärkning

Dynamiska sammansättningar använder inte flaggorna ReflectionPermissionFlag.MemberAccess och ReflectionPermissionFlag.RestrictedMemberAccess som tillåter dynamiska metoder att komma åt icke-offentliga typer och medlemmar.

Tillfälliga dynamiska sammansättningar skapas i minnet och sparas aldrig på disk, så de kräver inga behörigheter för filåtkomst. Att spara en dynamisk sammansättning på disk kräver FileIOPermission med lämpliga flaggor.

Generera dynamiska sammansättningar från delvis betrodd kod

Tänk på de villkor under vilka en sammansättning med Internetbehörigheter kan generera en tillfällig dynamisk sammansättning och köra dess kod:

  • Den dynamiska samlingen använder endast publika typer och medlemmar i andra samlingar.

  • De behörigheter som krävs av dessa typer och medlemmar ingår i beviljandeuppsättningen för den delvis betrodda sammansättningen.

  • Sammansättningen sparas inte på disken.

  • Felsökningssymboler genereras inte. (Internet och LocalIntranet behörighetsuppsättningar innehåller inte nödvändiga behörigheter.)

Anonymt värdbaserade dynamiska metoder

Anonymt värdbaserade dynamiska metoder skapas med hjälp av de två DynamicMethod konstruktorerna som inte anger någon associerad typ eller modul och DynamicMethod(String, Type, Type[])DynamicMethod(String, Type, Type[], Boolean). Dessa konstruktorer placerar de dynamiska metoderna i en systembaserad, fullständigt betrodd, säkerhetstransparent sammansättning. Inga behörigheter krävs för att använda dessa konstruktorer eller för att generera kod för de dynamiska metoderna.

När en anonymt värdbaserad dynamisk metod skapas registreras i stället anropsstacken. När metoden är konstruerad ställs säkerhetskrav mot den insamlade anropsstacken.

Anmärkning

Konceptuellt ställs krav under konstruktionen av metoden. Det vill säga: krav kan framföras när varje CIL-instruktion genereras. I den aktuella implementeringen ställs alla krav när DynamicMethod.CreateDelegate metoden anropas eller när jit-kompilatorn (just-in-time) anropas, om metoden anropas utan att anropa CreateDelegate.

Om programdomänen tillåter det kan anonymt värdbaserade dynamiska metoder hoppa över JIT-synlighetskontroller, med förbehåll för följande begränsning: De icke-offentliga typer och medlemmar som används av en anonymt värdbaserad dynamisk metod måste finnas i sammansättningar vars bidragsuppsättningar är lika med, eller delmängder av, bidragsuppsättningen för den sändande anropsstacken. Den här begränsade möjligheten att hoppa över JIT-synlighetskontroller är aktiverad om programdomänen beviljar ReflectionPermission med ReflectionPermissionFlag.RestrictedMemberAccess flaggan.

  • Om din metod endast använder offentliga typer och medlemmar krävs inga behörigheter under konstruktionen.

  • Om du anger att JIT-synlighetskontroller ska hoppas över, inkluderar ReflectionPermission det krav som görs när metoden skapas med ReflectionPermissionFlag.RestrictedMemberAccess flaggan och beviljandeuppsättningen för sammansättningen som innehåller den icke-offentliga medlem som används.

Eftersom bidragsuppsättningen för den icke-offentliga medlemmen beaktas kan kod med delvis förtroende som har beviljats ReflectionPermissionFlag.RestrictedMemberAccess inte höja sina behörigheter genom att köra icke-offentliga medlemmar i betrodda assemblyer.

Precis som med annan kod som genereras kräver körning av den dynamiska metoden vilka behörigheter som krävs av de metoder som den dynamiska metoden använder.

Systemsammansättningen som är värd för anonymt värdbaserade dynamiska metoder använder SecurityRuleSet.Level1 transparensmodellen, som är den transparensmodell som användes i .NET Framework före .NET Framework 4.

Mer information finns i DynamicMethod klassen .

Generera anonymt värdbaserade dynamiska metoder från delvis betrodd kod

Överväg de villkor under vilka en sammansättning med Internetbehörigheter kan generera en anonymt värdbaserad dynamisk metod och köra den:

  • Den dynamiska metoden använder endast offentliga typer och medlemmar. Om dess tillståndsuppsättning innehåller ReflectionPermissionFlag.RestrictedMemberAccess kan den använda icke-offentliga typer och medlemmar i alla assembly vars tillståndsuppsättning är lika med, eller en delmängd av, tillståndsuppsättningen för den utsändande assembly.

  • De behörigheter som krävs av alla typer och medlemmar som används av den dynamiska metoden ingår i behörighetsuppsättningen för den delvis betrodda assemblyn.

Anmärkning

Dynamiska metoder stöder inte felsökningssymboler.

Dynamiska metoder som är associerade med befintliga sammansättningar

Om du vill associera en dynamisk metod med en typ eller modul i en befintlig sammansättning använder du någon av konstruktorerna DynamicMethod som anger den associerade typen eller modulen. De behörigheter som krävs för att anropa dessa konstruktorer varierar, eftersom associera en dynamisk metod med en befintlig typ eller modul ger den dynamiska metoden åtkomst till icke-offentliga typer och medlemmar:

  • En dynamisk metod som är associerad med en typ har åtkomst till alla medlemmar av den typen, även privata medlemmar, och till alla interna typer och medlemmar i sammansättningen som innehåller den associerade typen.

  • En dynamisk metod som är associerad med en modul har åtkomst till alla internal typer och medlemmar (Friend i Visual Basic, assembly i vanliga språkkörningsmetadata) i modulen.

Dessutom kan du använda en konstruktor som anger möjligheten att hoppa över jit-kompilatorns synlighetskontroller. Detta ger din dynamiska metod åtkomst till alla typer och medlemmar i alla sammansättningar, oavsett åtkomstnivå.

Vilka behörigheter konstruktorn kräver beror på hur mycket åtkomst du bestämmer dig för att ge din dynamiska metod:

Även om objekten i den här listan beskrivs i tillståndsuppsättningen för den sändande sammansättningen, kom ihåg att kraven ställs mot den fullständiga anropsstacken, inklusive gränsen för applikationsdomänen.

Mer information finns i DynamicMethod klassen .

Generera dynamiska metoder från delvis betrodd kod

Anmärkning

Det rekommenderade sättet att generera dynamiska metoder från delvis betrodd kod är att använda anonymt värdbaserade dynamiska metoder.

Överväg de villkor under vilka en sammansättning med Internetbehörigheter kan generera en dynamisk metod och köra den:

  • Antingen är den dynamiska metoden associerad med modulen eller typen som genererar den, eller så innehåller ReflectionPermissionFlag.RestrictedMemberAccess dess beviljandeuppsättning och den är associerad med en modul i en sammansättning vars bidragsuppsättning är lika med, eller en delmängd av, beviljandeuppsättningen för den avsändande sammansättningen.

  • Den dynamiska metoden använder endast offentliga typer och medlemmar. Om dess beviljandeuppsättning innehåller ReflectionPermissionFlag.RestrictedMemberAccess och den är associerad med en modul i en sammansättning vars bidragsuppsättning är lika med, eller en delmängd av, beviljandeuppsättningen för den utsändande sammansättningen, kan den använda typer och medlemmar markerade internal (Friend i Visual Basic, assembly i vanliga språkkörningsmetadata) i den associerade modulen.

  • De behörigheter som krävs av alla typer och medlemmar som används av den dynamiska metoden ingår i beviljandeuppsättningen för den delvis betrodda sammansättningen.

  • Den dynamiska metoden hoppar inte över JIT-synlighetskontroller.

Anmärkning

Dynamiska metoder stöder inte felsökningssymboler.

Versionsinformation

Från och med .NET Framework 4 elimineras en maskinomfattande säkerhetspolicy och säkerhetstransparens blir standardverkställighetsmekanism.

Från och med .NET Framework 2.0 Service Pack 1, krävs ReflectionPermission tillsammans med ReflectionPermissionFlag.ReflectionEmit-flaggan inte längre när dynamiska sammansättningar och dynamiska metoder genereras. Den här flaggan krävs i alla tidigare versioner av .NET Framework.

Anmärkning

ReflectionPermission med ReflectionPermissionFlag.ReflectionEmit-flaggan ingår som standard i FullTrust och LocalIntranet-namngivna behörighetsuppsättningar, men inte i Internet-behörighetsuppsättningen. I tidigare versioner av .NET Framework kan därför ett bibliotek endast användas med Internetbehörigheter om det kör en Assert för ReflectionEmit. Sådana bibliotek kräver noggrann säkerhetsgranskning eftersom kodfel kan leda till säkerhetshål. .NET Framework 2.0 SP1 tillåter att kod genereras i partiella förtroendescenarier utan att utfärda några säkerhetskrav, eftersom det inte är en privilegierad åtgärd att generera kod. Den genererade koden har alltså inte fler behörigheter än den sammansättning som genererar den. På så sätt kan bibliotek som genererar kod vara säkerhetstransparenta och tar bort behovet av att kontrollera ReflectionEmit, vilket förenklar uppgiften att skriva ett säkert bibliotek.

Dessutom introducerar .NET Framework 2.0 SP1 ReflectionPermissionFlag.RestrictedMemberAccess-flaggan, som möjliggör åtkomst till icke-offentliga typer och medlemmar från delvis betrodda dynamiska metoder. Tidigare versioner av .NET Framework kräver ReflectionPermissionFlag.MemberAccess flaggan för dynamiska metoder som har åtkomst till icke-offentliga typer och medlemmar. Det här är en behörighet som aldrig bör beviljas till delvis betrodd kod.

Slutligen introducerar .NET Framework 2.0 SP1 anonymt värdbaserade metoder.

Hämta information om typer och medlemmar

Från och med .NET Framework 2.0 krävs inga behörigheter för att hämta information om icke-offentliga typer och medlemmar. Reflektion används för att hämta information som behövs för att generera dynamiska metoder. Objekt som MethodInfo används till exempel för att sända metodanrop. Tidigare versioner av .NET Framework kräver ReflectionPermission med ReflectionPermissionFlag.TypeInformation flaggan. Mer information finns i Säkerhetsöverväganden för reflektion.

Se även

  • Last updated on