Para ver el artículo en inglés, active la casilla Inglés. También puede ver el texto en inglés en una ventana emergente si pasa el puntero del mouse por el texto.
Traducción
Inglés

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 seguridad declarativa en el nivel de método y de tipo 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 se invalide 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 petición 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.

CA2153: Evitar el control de excepciones de estado dañadas

Las excepciones de estado dañado (CSE) indican que la memoria está dañada en el proceso. Detectar estos problemas y evitar el bloqueo del proceso puede provocar vulnerabilidades de seguridad si un atacante puede colocar una vulnerabilidad de seguridad en la región de memoria dañada.

CA3075: procesamiento no seguro de DTD

Si usa instancias de DTDProcessing inseguras o hace referencia a orígenes de entidades externas, el analizador podría aceptar entradas que no sean de confianza y revelar información confidencial a atacantes.

CA3076: Ejecución del script XSLT no segura

Si ejecuta el lenguaje de transformación basado en hojas de estilo (XSLT) en aplicaciones .NET de forma insegura, el procesador podría resolver referencias URI que no sean de confianza y que podrían revelar información confidencial a atacantes, dando lugar a ataques de denegación de servicio y entre sitios.

CA3077: procesamiento inseguro en el diseño de una API, documento XML y lector de texto XML

Al diseñar una API derivada de XMLDocument y XMLTextReader, tenga en cuenta la propiedad DtdProcessing. El uso de instancias de DTDProcessing inseguras al hacer referencia a orígenes de entidades externas o resolverlos, o la definición de valores inseguros en el lenguaje XML puede provocar la divulgación de información.

Mostrar: