Conjunto de reglas Reglas de seguridad para código administrado
Debe incluir el conjunto Reglas de seguridad de Microsoft para maximizar el número de posibles problemas de seguridad que se notifican.
Regla |
Descripción |
---|---|
Revisar las consultas SQL en busca de vulnerabilidades de seguridad |
|
Detectar excepciones que no son CLSCompliant en los controladores generales |
|
Revisar la seguridad imperativa |
|
No declarar tipos de referencias mutables de sólo lectura |
|
Los campos de matrices no deben ser de sólo lectura |
|
Asegurar aserciones |
|
Revisar el uso de Deny y PermitOnly |
|
Revisar la seguridad declarativa en los tipos de valor |
|
Revisar los controladores de eventos visibles |
|
Los punteros no deberían estar visibles |
|
Los tipos seguros no deberían exponer campos |
|
La seguridad del método debería ser un supraconjunto del tipo |
|
Llamar a GC.KeepAlive cuando se utilicen recursos nativos |
|
Los métodos APTCA deben llamar solo a métodos APTCA |
|
Los tipos APTCA sólo amplían tipos base APTCA |
|
Revisar el uso de SuppressUnmanagedCodeSecurityAttribute |
|
Sellar los métodos que cumplan las interfaces privadas |
|
Proteger los constructores de serializaciones |
|
Los constructores estáticos deberían ser privados |
|
No exponer indirectamente métodos con peticiones de vínculos |
|
Las peticiones de vínculos de reemplazo deberían ser idénticas a la base |
|
Incluir cláusulas Finally vulnerables en un bloque Try externo |
|
Las peticiones de vínculos de tipos requieren peticiones de herencias |
|
Las constantes críticas para la seguridad deben ser transparentes |
|
Los tipos críticos para la seguridad no pueden participar en la equivalencia de tipos |
|
Los constructores predeterminados deben ser al menos tan críticos para la seguridad como los constructores predeterminados de tipo base. |
|
Los delegados deben enlazarse a métodos con una transparencia coherente |
|
Los métodos deben mantener una transparencia coherente cuando reemplazan métodos base |
|
Los ensamblados de nivel 2 no deben contener LinkDemands |
|
Los miembros no deben tener anotaciones de transparencia en conflicto |
|
Los métodos transparentes deben contener solo IL que se pueda comprobar |
|
Los métodos transparentes no deben llamar a métodos con el atributo SuppressUnmanagedCodeSecurity |
|
Los métodos transparentes no pueden usar el atributo HandleProcessCorruptingExceptions |
|
El código transparente no debe hacer referencia a elementos críticos para la seguridad |
|
Los métodos transparentes no deben satisfacer LinkDemands |
|
El código transparente no se debería proteger con LinkDemands |
|
Los métodos transparentes no deben usar peticiones de seguridad |
|
El código transparente no debe cargar ensamblados desde matrices de bytes |
|
Los métodos transparentes no deben ser representativos con el atributo SuppressUnmanagedCodeSecurityAttribute |
|
Los tipos deben ser al menos tan críticos para la seguridad como sus interfaces y tipos base. |
|
Los métodos transparentes no pueden usar aserciones de seguridad |
|
Los métodos transparentes no deben llamar a código nativo |
|
Los ensamblados deben tener nombres seguros válidos |