Advertencias de seguridad

Las advertencias de seguridad son compatibles con las bibliotecas y aplicaciones más seguras.Estas advertencias ayudan a evitar los errores de seguridad en su programa.Si deshabilita cualquier advertencia de este tipo, se debe indicar el motivo claramente en el código además de informar al responsable de seguridad designado a ese proyecto de desarrollo.

En esta sección

Regla	Descripción
CA2100: Revisar las consultas SQL en busca de vulnerabilidades de seguridad	Un método establece la propiedad System.Data.IDbCommand.CommandText utilizando una cadena que se construye partiendo de un argumento de cadena para el método.Esta regla supone que el argumento de cadena contiene datos proporcionados por el usuario.Una cadena de comandos de SQL compilada a partir de datos proporcionados por el usuario es vulnerable a ataques de inserción de SQL.
CA2102: Detectar las excepciones que no son CLSCompliant en los controladores generales	Un miembro de un ensamblado que no está marcado con el atributo RuntimeCompatibilityAttribute o está marcado con RuntimeCompatibility(WrapNonExceptionThrows = false) contiene un bloque catch que controla el objeto System.Exception y no contiene un bloque catch general inmediatamente después.
CA2103: Revisar la seguridad imperativa	Un método utiliza la seguridad imperativa y podría estar creando el permiso utilizando la información de estado y los valores devueltos que pueden cambiar mientras la solicitud está activa.Utilice la seguridad declarativa siempre que sea posible.
CA2104: No declarar tipos de referencias mutables de solo lectura	Un tipo visible externamente contiene un campo de sólo lectura visible externamente que es un tipo de referencia que se puede cambiar.Un tipo que mutable es un tipo cuyos datos de instancia se pueden modificar.
CA2105: Los campos de matrices no deberían ser de solo lectura	Cuando se aplica el modificador de solo lectura (ReadOnly en Visual Basic) a un campo que contiene una matriz, el campo no se puede modificar para hacer referencia a una matriz distinta.Sin embargo, se pueden cambiar los elementos de la matriz almacenados en un campo de sólo lectura.
CA2106: Asegurar aserciones	Un método valida un permiso y no se realiza ninguna comprobación de seguridad en el llamador.Validar un permiso de seguridad sin realizar ninguna comprobación de seguridad puede dejar una debilidad de seguridad explotable en el código.
CA2107: Revisar el uso de Deny y PermitOnly	Utilizando el método PermitOnly y CodeAccessPermission.Deny solamente se debe utilizar acciones de seguridad si se conoce en profundidad la seguridad de .NET Framework.Debería realizarse una revisión de la seguridad del código que utiliza estas acciones de seguridad.
CA2108: Revisar la seguridad declarativa en los tipos de valor	Un tipo de valor público o protegido está protegido por acceso a datos o peticiones de vínculos.
CA2109: Revisar los controladores de eventos visibles	Se detectó un método de control de eventos público o protegido.No se deberían exponer los métodos de control de eventos a menos que sea absolutamente necesario.
CA2111: Los punteros no deberían estar visibles	Un puntero no es privado, interno ni de solo lectura.El código malintencionado puede cambiar el valor del puntero, permitiendo potencialmente el acceso a ubicaciones arbitrarias en memoria o provocando errores del sistema o de aplicación.
CA2112: Los tipos seguros no deberían exponer campos	Un tipo público o protegido contiene campos públicos y está protegido por peticiones de vínculos.Si el código tiene acceso a una instancia de tipo que está protegida por una solicitud de vínculo, el código no cumplirá la solicitud para obtener acceso a los campos del tipo.
CA2114: La seguridad del método debería ser un supraconjunto del tipo	Un método no debe tener un nivel de método ni un nivel de tipo seguridad declarativa para la misma acción.
CA2115: Llamar a GC.KeepAlive cuando se utilicen recursos nativos	Esta regla detecta errores que pueden haberse producido porque se finaliza un recurso no administrado mientras todavía se utiliza en código no administrado.
CA2116: Los métodos APTCA deben llamar solo a métodos APTCA	Si está presente el atributo APTCA (AllowPartiallyTrustedCallers) en un ensamblado de plena confianza y el ensamblado ejecuta código en otro ensamblado que permite llamadores parcialmente confiables, se puede producir un ataque en el sistema de seguridad.
CA2117: Los tipos APTCA solo amplían tipos base APTCA	Si está presente el atributo APTCA (AllowPartiallyTrustedCallers) en un ensamblado de plena confianza y un tipo del ensamblado se hereda de otro que permite llamadores parcialmente confiables, se puede producir un ataque de seguridad.
CA2118: Revisar el uso de SuppressUnmanagedCodeSecurityAttribute	SuppressUnmanagedCodeSecurityAttribute cambia el comportamiento del sistema de seguridad predeterminado por miembros que ejecutan código no administrado que utiliza la interoperabilidad COM o la invocación de plataforma.Este atributo se utiliza principalmente para aumentar el rendimiento; sin embargo, las mejoras de rendimiento suponen riesgos de seguridad importantes.
CA2119: Sellar los métodos que cumplan las interfaces privadas	Un tipo público heredable proporciona una implementación de método reemplazable de una interfaz interna (de tipo "Friend" en Visual Basic).Para corregir una infracción de esta regla, impida que el método sea reemplazado fuera del ensamblado.
CA2120: Proteger los constructores de serializaciones	Este tipo tiene un constructor que toma un objeto System.Runtime.Serialization.SerializationInfo y un objeto System.Runtime.Serialization.StreamingContext (la firma del constructor de serialización).Una comprobación de seguridad no protege este constructor, pero protege uno o más constructores regulares del tipo.
CA2121: Los constructores estáticos deberían ser privados	El sistema llama al constructor estático antes de crear la primera instancia del tipo o antes de hacer referencia a cualquier miembro estático.Si un constructor estático no es privado, se puede llamar a través de un código distinto del sistema.En función de las operaciones que se realizan en el constructor, esto puede producir un comportamiento inesperado.
CA2122: No exponer indirectamente métodos con peticiones de vínculos	Un miembro público o protegido tiene peticiones de vínculos y lo llama un miembro que no realiza ninguna comprobación de seguridad.Una solicitud de vínculo sólo comprueba los permisos del llamador inmediato.
CA2123: Las peticiones de vínculos de reemplazo deberían ser idénticas a la base	Esta regla compara un método con su método base, que es una interfaz o un método virtual de otro tipo y, a continuación, compara las solicitudes de vínculos en cada uno.Si se infringe esta regla, un llamador malintencionado puede omitir la solicitud de vínculo tan solo con llamar al método no seguro.
CA2124: Incluir cláusulas Finally vulnerables en un bloque Try externo	Un método público o protegido contiene un bloque try-finally.El bloque finally aparece para restablecer el estado de seguridad y no se incluye a sí mismo en un bloque finally.
CA2126: Las peticiones de vínculos de tipos requieren peticiones de herencias	Un tipo público no sellado está protegido con una petición de vínculo y tiene un método reemplazable.Ni el tipo ni el método están protegidos con una petición de herencia.
CA2136: Los miembros no deben tener anotaciones de transparencia en conflicto	No puede haber código crítico en un ensamblado 100% transparente.Esta regla analiza los ensamblados 100% transparentes para detectar cualquier anotación de SecurityCritical en los niveles de tipo, campo y método.
CA2147: Los métodos transparentes no pueden usar aserciones de seguridad	Esta regla analiza todos los métodos y tipos de un ensamblado que es 100% transparente o tiene una mezcla de transparente y crítico, y marca cualquier uso declarativo o imperativo de Assert.
CA2140: El código transparente no debe hacer referencia a elementos críticos para la seguridad	Los métodos que se marcan con el atributo SecurityTransparentAttribute llaman a miembros no públicos marcados como SecurityCritical.Esta regla analiza todos los métodos y tipos de un ensamblado que tiene una mezcla de transparente y crítico, y marca las llamadas desde código transparente a código crítico no público que no están marcadas como SecurityTreatAsSafe.

CA2130: Las constantes críticas para la seguridad deben ser transparentes	El cumplimiento de la transparencia no se exige para los valores constantes porque los compiladores alinean los valores constantes para que no se requiera ninguna búsqueda en tiempo de ejecución.Los campos constantes deberían ser transparentes en seguridad de modo que los revisores del código no supongan que el código transparente no puede tener acceso a la constante.
CA2131: Los tipos críticos para la seguridad no pueden participar en la equivalencia de tipos	Un tipo participa en la equivalencia de tipos y el propio tipo, o un miembro o campo del tipo, se marca mediante el atributo SecurityCriticalAttribute.Esta regla se produce en todos los tipos críticos o en los tipos que contienen métodos o campos críticos que participan en la equivalencia de tipos.Cuando CLR detecta esta clase de tipo, no lo carga con TypeLoadException en tiempo de ejecución.Normalmente, esta regla solo se desencadena cuando los usuarios implementan la equivalencia de tipos manualmente en lugar de confiar en tlbimp y los compiladores para hacer la equivalencia de tipos.
CA2132: Los constructores predeterminados deben ser al menos tan críticos para la seguridad como los constructores predeterminados de tipo base	El código de la aplicación Silverlight no puede usar los tipos y miembros con SecurityCriticalAttribute.El código de confianza puede utilizar solo tipos y miembros críticos para la seguridad en .NET Framework para la biblioteca de clases de Silverlight.Dado que una construcción pública o protegida en una clase derivada debe tener la misma transparencia, o mayor, que su clase base, una clase de una aplicación no puede derivar de una clase marcada como SecurityCritical.
CA2133: Los delegados deben enlazarse a métodos con una transparencia coherente	Esta advertencia se desencadena en un método que enlaza un delegado que se marca con SecurityCriticalAttribute a un método que es transparente o que está marcado con SecuritySafeCriticalAttribute.La advertencia también desencadena un método que enlaza un delegado que es transparente o crítico para la seguridad a un método crítico.
CA2134: Los métodos deben mantener una transparencia coherente cuando reemplazan métodos base	Esta regla se desencadena cuando un método marcado con SecurityCriticalAttribute invalida un método que es transparente o está marcado con SecuritySafeCriticalAttribute.Esta regla también se desencadena cuando un método marcado con SecuritySafeCriticalAttribute invalida un método que es transparente o está marcado con SecurityCriticalAttribute.Se aplica la regla al invalidar un método virtual o implementar una interfaz.
CA2135: Los ensamblados de nivel 2 no deben contener LinkDemands	LinkDemands está desusado en el conjunto de reglas de seguridad de nivel 2.En lugar de utilizar LinkDemands para exigir la seguridad en el momento de la compilación Just-In-Time (JIT), marque los métodos, tipos y campos con el atributo SecurityCriticalAttribute.
CA2136: Los miembros no deben tener anotaciones de transparencia en conflicto	Los atributos de transparencia se aplican de los elementos de código de ámbito mayor a los elementos de ámbito menor.Los atributos de transparencia de los elementos de código con mayor ámbito tienen prioridad sobre los atributos de transparencia de los elementos de código incluidos en el primer elemento.Por ejemplo, una clase marcada con el atributo SecurityCriticalAttribute no puede contener un método marcado con el atributo SecuritySafeCriticalAttribute.
CA2137: Los métodos transparentes deben contener solo IL que se pueda comprobar	Un método contiene código que no se puede comprobar o devuelve un tipo por referencia.Esta regla se desencadena en los intentos del código transparente en seguridad de ejecutar MSIL no comprobable (Lenguaje intermedio de Microsoft).Sin embargo, la regla no contiene un comprobador de IL completo y, en su lugar, utiliza la heurística para detectar la mayoría de las infracciones de comprobación MSIL.
CA2138: Los métodos transparentes no deben llamar a métodos con el atributo SuppressUnmanagedCodeSecurity	Un método transparente en seguridad llama a un método marcado con el atributo SuppressUnmanagedCodeSecurityAttribute.
CA2139: Los métodos transparentes no pueden usar el atributo HandleProcessCorruptingExceptions	Esta regla desencadena cualquier método que sea transparente e intenta controlar una excepción de daño de proceso utilizando el atributo HandleProcessCorruptedStateExceptionsAttribute.Una excepción de daño de proceso en la versión 4.0 de CLR es una clasificación de excepciones como AccessViolationException.El atributo HandleProcessCorruptedStateExceptionsAttribute solo lo pueden utilizar los métodos críticos para la seguridad, y se omitirá si se aplica a un método transparente.
CA2140: El código transparente no debe hacer referencia a elementos críticos para la seguridad	Un elemento de código que se marca con el atributo SecurityCriticalAttribute es crítico para la seguridad.Un método transparente no puede utilizar un elemento crítico para la seguridad.Si un tipo transparente intenta usar un tipo crítico para la seguridad, se produce una excepción TypeAccessException, MethodAccessException o FieldAccessException.
CA2141: Los métodos transparentes no deben satisfacer LinkDemands	Un método transparente en seguridad llama a un método de un ensamblado no marcado con APTCA (AllowPartiallyTrustedCallersAttribute) o bien satisface un LinkDemand para un tipo o un método.
CA2142: El código transparente no se debería proteger con LinkDemands	Esta regla se desencadena en los métodos transparentes que requieren que las LinkDemand tengan acceso a ellos.El código transparente en seguridad no debería ser responsable de comprobar la seguridad de una operación y, por consiguiente, no debería exigir permisos.
CA2143: Los métodos transparentes no deben usar peticiones de seguridad	El código transparente en seguridad no debería ser responsable de comprobar la seguridad de una operación y, por consiguiente, no debería exigir permisos.El código transparente en seguridad debería utilizar peticiones completas para tomar decisiones de seguridad y el código crítico para la seguridad no debió confiar en el código transparente al realizar la petición completa.
CA2144: El código transparente no debe cargar ensamblados desde matrices de bytes	La revisión de seguridad del código transparente no es tan exhaustiva como la revisión de seguridad del código crítico, porque el código transparente no puede realizar acciones que afectan a la seguridad.Los ensamblados cargados desde una matriz de bytes podrían no distinguirse en el código transparente, y esa matriz de bytes podría contener código importante crítico para la seguridad, que no hace falta auditar.
CA2145: Los métodos transparentes no deben ser representativos con el atributo SuppressUnmanagedCodeSecurityAttribute	Los métodos decorados con el atributo SuppressUnmanagedCodeSecurityAttribute tienen una LinkDemand implícita colocada en cualquier método que la llame.Esta LinkDemand requiere que el código de llamada sea crítico para la seguridad.Marcar el método que utiliza SuppressUnmanagedCodeSecurity con el atributo SecurityCriticalAttribute hace este requisito más obvio para los llamadores del método.
CA2146: Los tipos deben ser al menos tan críticos para la seguridad como sus interfaces y tipos base	Esta regla se desencadena cuando un tipo derivado tiene un atributo de transparencia de seguridad que no es tan crítico como su tipo base o interfaz implementada.Solo los tipos críticos pueden derivar de los tipos base críticos o implementar interfaces críticas, y solo los tipos críticos o críticos para la seguridad pueden derivar de tipos base críticos para la seguridad o implementar interfaces críticas para la seguridad.
CA2147: Los métodos transparentes no pueden usar aserciones de seguridad	El código marcado como SecurityTransparentAttribute no tiene permisos suficientes para imponerse.
CA2149: Los métodos transparentes no deben llamar a código nativo	Esta regla se desencadena en cualquier método transparente que llame directamente a código nativo, por ejemplo, a través de P/Invoke.Las infracciones de esta regla tienen como resultado una excepción MethodAccessException en el modelo de transparencia de nivel 2 y una demanda completa de UnmanagedCode en el modelo de transparencia de nivel 1.
CA2151: Los campos con tipos críticos deben ser críticos para la seguridad	Para utilizar tipos críticos para la seguridad, el código que hace referencia al tipo debe ser crítico para la seguridad o crítico para la seguridad y disponible desde código transparente.Esto es así incluso si la referencia es indirecta.Por consiguiente, tener un campo transparente para la seguridad o crítico para la seguridad y disponible desde código transparente puede llevar a confusión, porque el código transparente todavía no podrá tener acceso al campo.
CA5122: Las declaraciones P/Invoke no deben ser críticas para la seguridad	Los métodos se marcan como SecuritySafeCritical cuando realizan una operación que afecta a la seguridad pero también son seguros para su uso en código transparente.El código transparente nunca puede llamar a código nativo a través de P/Invoke.Por consiguiente, aunque se marque P/Invoke como crítico para la seguridad y disponible desde código transparente no permitirá que se llame desde código transparente llamarlo, y es erróneo para los análisis de seguridad.