SecurityTransparent-Code sollte nicht auf nicht öffentliche sicherheitsrelevante Member verweisen
Aktualisiert: November 2007
TypeName |
SecurityTransparentCodeShouldNotReferenceNonpublicSecurityCriticalCode |
CheckId |
CA2129 |
Kategorie |
Microsoft.Security |
Unterbrechende Änderung |
Breaking |
Ursache
Mit SecurityTransparentAttribute markierte Methoden rufen nicht öffentliche Member auf, die als SecurityCritical markiert sind. SecurityTransparent ist die Standardbezeichnung für Methoden.
Regelbeschreibung
In .NET Framework 2.0 wurde ein Feature mit dem Namen Transparenz eingeführt. Einzelne Methoden, Felder, Schnittstellen, Klassen und Typen können entweder sicherheitstransparent oder sicherheitsrelevant sein.
In transparentem Code können Sicherheitsberechtigungen nicht ausgeweitet werden. Daher werden alle durch Code gewährten oder angeforderten Berechtigungen automatisch durch den Code an den Aufrufer oder die Domäne der Hostanwendung weitergeleitet. Beispiele für Rechteerweiterungen sind Assertionen, LinkDemands, SuppressUnmanagedCode und unsicherer Code.
Durch die Unterteilung in sicherheitstransparenten und sicherheitsrelevanten Code soll die Überwachung der Sicherheit vereinfacht werden. Überprüfungen werden normalerweise an öffentlichen Einstiegspunkten ausgeführt, da dort das Risiko von bösartiger, nicht vertrauenswürdiger öffentlicher Nutzung besteht. Indem kleinere Abschnitte einer Assembly als relevant markiert werden, kann die Sicherheitsüberprüfung auf öffentliche Einstiegspunkte und sicherheitsrelevante Codeabschnitte beschränkt werden, durch die Berechtigungen ausgeweitet werden. Um sicherzustellen, dass die Überprüfung präzise und vollständig verläuft, muss die Unterteilung zwischen transparentem und relevantem Code so strikt wie möglich durchgesetzt werden. Die Alternative würde darin bestehen, Aufrufe von transparentem Code an internen sicherheitsrelevanten Code zuzulassen, wodurch der transparente Code viel stärker überwacht werden müsste.
Der Just-In-Time-Compiler der Common Language Runtime überprüft zur Laufzeit, ob transparenter Code auf nicht öffentlichen, sicherheitsrelevanten Code verweist oder diesen aufruft. Wenn nicht öffentlicher, relevanter Code von transparentem Code aufgerufen wird, wird eine Ausnahme wie MethodAccessException ausgelöst. Dieses Szenario wird ähnlich behandelt wie eine Klasse, die versucht, auf die privaten Member einer anderen Klasse zuzugreifen.
Durch diese Codeanalyseregel werden alle Methoden und Typen in einer Assembly analysiert, in der transparenter/relevanter Code kombiniert ist. Außerdem werden durch die Regel alle Aufrufe von transparentem an nicht öffentlichen, relevanten Code gekennzeichnet, die nicht als SecurityTreatAsSafe markiert sind.
Behandlung von Verstößen
Um dieses Problem zu beheben, markieren Sie entweder den Code, durch den der nicht öffentliche SecurityCritical-Code aufgerufen wird, als SecurityCritical oder markieren die Zielmethode/den Zieltyp als SecurityTreatAsSafe. Auf diese Weise wird der Code wirkungsvoll als öffentlicher, sicherer Code behandelt und zum Schutz vor böswilligen Zugriffen überprüft.
Wann sollten Warnungen unterdrückt werden?
Unterdrücken Sie keine Meldung dieser Regel.
Beispiel
Der folgende Code verursacht einen Fehler, da SecondSecurityMethod privat und SecurityCritical ist. Beispiel für ein Sicherheitsproblem: Die Assertion in SecondSecurityMethod verhindert die Weiterleitung vollständiger Anforderungen in privilegierten Aktionen und ausgehenden Aufrufen an FirstSecurityMethod, da der Vorgang auf die für den Aufrufer ausgeführten Sicherheitsüberprüfungen beschränkt ist.
using System;
using System.Security.Permissions;
namespace SecurityTestClassLibrary
{
public class SecurityTestClass
{
// SecurityTransparent
public void FirstSecurityMethod()
{
SecondSecurityMethod();
}
[System.Security.SecurityCritical]
private void SecondSecurityMethod()
{
// Assert permissions
// do privileged actions, such as method call-outs
}
}
}
Wenn die Trennung zwischen transparent/relevant nicht durchgesetzt würde, wäre FirstSecurityMethod in der Lage, alle Aktionen von SecondSecurityMethod ohne Sicherheitsüberprüfungen auszuführen.
Eine Möglichkeit besteht darin, den Methodencode zu überprüfen und die Methode mit SecurityTreatAsSafe zu markieren, sofern sie in Bezug auf die Rechteerweiterung und auf böswillige Angriffe als sicher betrachtet werden kann:
using System;
using System.Security.Permissions;
namespace SecurityTestClassLibrary
{
public class SecurityTestClass
{
// SecurityTransparent
public void FirstSecurityMethod()
{
SecondSecurityMethod();
}
[System.Security.SecurityTreatAsSafe]
[System.Security.SecurityCritical]
private void SecondSecurityMethod()
{
// Assert permissions
// do privileged actions, such as method call-outs
}
}
}
Eine andere Möglichkeit besteht darin, Method1 auch als relevant einzustufen. Auf diese Weise wird der relevante Kernel der Assembly erweitert und der Umfang der Sicherheitsüberprüfung vergrößert. Darüber hinaus ist gewährleistet, dass geeignete Bedrohungsmodelle erstellt und Codeflussanalysen durchgeführt werden.
using System;
using System.Security.Permissions;
namespace SecurityTestClassLibrary
{
public class SecurityTestClass
{
[System.Security.SecurityCritical]
public void FirstSecurityMethod()
{
SecondSecurityMethod();
}
[System.Security.SecurityCritical]
private void SecondSecurityMethod()
{
// Assert permissions
// do privileged actions, such as method call-outs
}
}
}