Exportar (0) Imprimir
Expandir todo
Expandir Minimizar
Este artículo proviene de un motor de traducción automática. Mueva el puntero sobre las frases del artículo para ver el texto original. Más información.
Traducción
Original
Este tema aún no ha recibido ninguna valoración - Valorar este tema

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.

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 comando SQL compilada a partir de datos proporcionados por el usuario es vulnerable a ataques pon inyección de código 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. La aserción de un permiso de seguridad sin realizar ninguna comprobación de seguridad puede hacer que la seguridad del código sea débil.

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 (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 para la seguridad no debe ser responsable de comprobar la seguridad de una operación y, por tanto, no debe pedir permisos.

CA2143: Los métodos transparentes no deben usar peticiones de seguridad

El código transparente para la seguridad no debe ser responsable de comprobar la seguridad de una operación y, por tanto, no debe pedir 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. Este LinkDemand requiere que el código que llama 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.

¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios

Adiciones de comunidad

AGREGAR
Mostrar:
© 2014 Microsoft. Reservados todos los derechos.