Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Sie sollten den Regelsatz für die Microsoft-Sicherheitsregeln einschließen, um die Anzahl der potenziellen Sicherheitsprobleme, die gemeldet werden, zu maximieren.
Regel |
Beschreibung |
|---|---|
SQL-Abfragen auf Sicherheitsrisiken überprüfen |
|
Nicht-CLSCompliant-Ausnahmen in allgemeinen Handlern abfangen |
|
Imperative Sicherheit überprüfen |
|
Schreibgeschützte änderbare Referenztypen nicht deklarieren |
|
Arrayfelder dürfen nicht schreibgeschützt sein |
|
Sichere Bestätigungen |
|
Verwendung von Deny und PermitOnly überprüfen |
|
Deklarative Sicherheit auf Werttypen überprüfen |
|
Sichtbare Ereignishandler überprüfen |
|
Zeiger sollten nicht sichtbar sein. |
|
Gesicherte Typen sollten keine Felder verfügbar machen. |
|
Methodensicherheit sollte Superset des Typs sein |
|
GC.KeepAlive beim Verwenden systemeigener Ressourcen aufrufen |
|
APTCA-Methoden sollten nur APTCA-Methoden aufrufen |
|
APTCA-Typen sollten nur APTCA-Basistypen erweitern |
|
Verwendung von SuppressUnmanagedCodeSecurityAttribute prüfen |
|
Methoden versiegeln, die die Bedingungen privater Schnittstellen erfüllen |
|
Sichere Serialisierungskonstruktoren |
|
Statische Konstruktoren sollten privat sein. |
|
Methoden mit Linkaufrufen nicht indirekt verfügbar machen |
|
Überschreibungslinkaufrufe sollten zur Basis identisch sein |
|
Anfällige finally-Klauseln mit äußerem try-Block umschließen |
|
Typlinkaufrufe erfordern Vererbungsanforderungen |
|
Sicherheitsrelevante Konstanten sollten transparent sein |
|
Sicherheitsrelevante Typen werden möglicherweise nicht an Typäquivalenz beteiligt |
|
Standardkonstruktoren müssen mindestens so kritisch sein wie die Standardkonstruktoren des Basistyps. |
|
Delegaten müssen an Methoden mit Transparenz konsistenter binden |
|
Methoden müssen konsistente Transparenz halten, während sie Basismethoden überschreiben |
|
Assemblys der Ebene 2 sollten LinkDemands nicht enthalten |
|
Member sollten in Konflikt stehende Transparenzanmerkungen aufweisen |
|
Transparente Methoden müssen nur überprüfbares IL enthalten |
|
Transparente Methoden dürfen Methoden mit dem SuppressUnmanagedCodeSecurity-Attribut nicht aufrufen |
|
Transparente Methoden verwenden möglicherweise nicht das HandleProcessCorruptingExceptions-Attribut |
|
Transparenter Code darf sicherheitsrelevante Elemente verweisen |
|
Transparente Methoden dürfen LinkDemands nicht erfüllen |
|
Transparenter Code sollte nicht mit LinkDemands geschützt werden |
|
Transparente Methoden sollten Sicherheitsanforderungen nicht verwenden |
|
Transparenter Code sollte Assemblys aus Bytearrays nicht laden |
|
Transparente Methoden sollten nicht mit dem SuppressUnmanagedCodeSecurityAttribute ergänzt werden |
|
Typen müssen mindestens genauso kritisch sein wie ihre Basistypen und Schnittstellen. |
|
Transparente Methoden können nicht Sicherheitsassertions |
|
Transparente Methoden dürfen nicht in systemeigenen Code aufrufen |
|
Assemblys müssen gültige starke Namen aufweisen |