Denegación de servicio

La denegación de servicio se produce cuando un sistema está sobrecargado de tal manera que no se pueden procesar los mensajes, o se procesan muy lentamente.

Consumo de memoria de exceso

Al leer un documento XML con numerosos nombres locales, espacios de nombres o prefijos únicos, puede producirse un problema. Si está utilizando una clase que se deriva de XmlReader, y llama a la propiedad LocalName, Prefix o NamespaceUri para cada elemento, la cadena devuelta se agrega a NameTable. La colección contenida por NameTable nunca disminuye de tamaño, creando una "pérdida de memoria" virtual de los identificadores de cadena.

Las mitigaciones incluyen:

• Derive de la clase NameTable y exija una cuota de tamaño máximo. (No puede evitar el uso de NameTable o intercambiar NameTable cuando es completo.)

• Evite el uso de las propiedades mencionadas y utilice en su lugar el método MoveToAttribute con el método IsStartElement cuando sea posible; estos métodos no devuelven cadenas y, por tanto, evitan el problema de llenar demasiado la colección NameTable.

Cliente malintencionado envía solicitudes de licencia en exceso al servicio

Si un cliente malintencionado bombardea un servicio con solicitudes de licencia excesivas, puede hacer que el servidor utilice memoria en exceso.

Mitigación: use las propiedades siguientes de la clase LocalServiceSecuritySettings:

• MaxCachedCookies: controla el número máximo de SecurityContextTokens limitados por tiempo que el servidor almacena en memoria caché después de SPNego o negociación SSL.

• IssuedCookieLifetime: controla la duración de SecurityContextTokens que el servidor emite tras SPNego o una negociación SSL. El servidor almacena en memoria caché los SecurityContextTokens para este período de tiempo.

• MaxPendingSessions: controla el número máximo de conversaciones seguras que se establecen en el servidor pero para las que no se ha procesado ningún mensaje de aplicación. Esta cuota evita que los clientes establezcan conversaciones seguras en el servicio, por lo que el servicio mantiene el estado por cliente, pero sin usarlos.

• InactivityTimeout: controla el tiempo máximo en el que el servicio mantiene viva una conversación segura sin recibir un mensaje de aplicación del cliente para la conversación. Esta cuota evita que los clientes establezcan conversaciones seguras en el servicio, por lo que el servicio mantiene el estado por cliente, pero sin usarlos.

WSDualHttpBinding o los enlaces personalizados duales requieren autenticación del cliente

De forma predeterminada, WSDualHttpBinding tiene la seguridad habilitada. Es posible, sin embargo, que si la autenticación del cliente se deshabilita estableciendo la propiedad ClientCredentialType en None, un usuario malintencionado pueda producir un ataque de denegación de servicio en un tercer servicio. Esto se puede producir porque un cliente malintencionado puede hacer que el servicio envíe una secuencia de mensajes a un tercer servicio.

Para mitigarlo, no establezca la propiedad en None. También sea consciente de esta posibilidad al crear un enlace personalizado que tiene un modelo de mensaje dual.

Se puede rellenar el registro de eventos de auditoría

Si un usuario malintencionado sabe que la auditoría está habilitada, el atacante puede enviar mensajes no válidos y así hacer que se escriban entradas de auditoría. Si el registro de auditoría se rellena de esta manera, el sistema de auditoría falla.

Para mitigar esta situación, establezca la propiedad SuppressAuditFailure en true y use las propiedades del visor de eventos para controlar el comportamiento de la auditoría. Para obtener más información sobre cómo usar el visor de eventos para ver y administrar los registros de eventos, vea Visor de eventos. Para obtener más información, vea Auditoría de eventos de seguridad.

Las implementaciones no válidas de IAuthorizationPolicy pueden hacer que el servicio no responda

Llamar al método Evaluate en una implementación defectuosa de la interfaz IAuthorizationPolicy puede hacer que el servicio no responda.

Mitigación: utilice solamente código de confianza. Es decir, solo utilice código que haya escrito y probado, o que provenga de un proveedor confiable. No permita la conexión de extensiones que no son de confianza de IAuthorizationPolicy a su código sin la debida consideración. Esto se aplica a todas las extensiones usadas en una implementación de servicio. WCF no realiza distinciones entre el código de aplicación y el código extranjero que se conecta para utilizar puntos de extensibilidad.

Puede que el tamaño máximo del token de Kerberos necesite cambio de tamaño

Si un cliente pertenece a un número grande de grupos (aproximadamente 900, aunque el número real varía dependiendo de los grupos), puede producirse un problema cuando el bloque de un encabezado de mensaje supera los 64 kilobytes. En ese caso, puede aumentar el tamaño máximo de token de Kerberos, como se describe en el artículo del Soporte técnico de Microsoft La Autenticación de Kerberos de Internet Explorer no funciona debido a un búfer insuficiente al conectarse a IIS." También puede que necesite aumentar el tamaño máximo del mensaje WCF para alojar un token más grande de Kerberos.

La inscripción automática da como resultado varios certificados con el mismo nombre de asunto para el equipo

La inscripción automática es la funcionalidad de Windows Server 2003 para inscribir automáticamente usuarios y equipos para certificados. Cuando un equipo está en un dominio con la característica habilitada, se crea automáticamente un certificado X.509 con el propósito intencional de autenticación del cliente y se inserta en el almacén de certificados personales del equipo local siempre que un nuevo equipo se une a la red. Sin embargo, la inscripción automática utiliza el mismo nombre de sujeto para todos los certificados que crea en la memoria caché.

El resultado es que los servicios WCF puede que fallen a la hora de abrir dominios con la inscripción automática. Esto se produce porque el criterio de búsqueda de credenciales X.509 de servicio predeterminado podría ser ambiguo, ya que existen varios certificados con nombre completo del Domain Name System (DNS). Un certificado ha sido originado por la inscripción automática; el otro puede ser un certificado emitido por sí mismo.

Para mitigar esto, haga referencia al certificado exacto que hay que utilizar, utilizando un criterio de búsqueda más preciso en serviceCredentials element. Por ejemplo, utilice la opción FindByThumbprint y especifique el certificado por su huella digital única (hash).

Para obtener más información sobre la característica de inscripción automática, vea Inscripción automática en Windows Server 2003.

Último de varios nombres de asunto alternativos que se usan en la autorización

En el poco probable caso de que un certificado X.509 contenga varios nombres de asunto alternativos, y que usted autorice el uso del nombre de asunto alternativo, puede que se produzca un error en la autorización.

Proteger los archivos de configuración con ACL

Puede especificar demandas necesarias y opcionales en código y archivos de configuración para los tokens emitidos CardSpace. Esto tiene como resultado que se emitan elementos correspondientes en mensajes RequestSecurityToken que se envían al servicio de token de seguridad. Un atacante puede modificar código o configuración para eliminar demandas necesarias u opcionales, pudiendo ganar así la posibilidad de que el servicio de token de seguridad emita un token que no permite el acceso al servicio especificado.

Para mitigar: exija el acceso al equipo para modificar el archivo de configuración. Utilice listas de control de acceso a archivos (ACL) para proteger los archivos de configuración. WCF requiere que ese código esté en el directorio de aplicaciones o en la caché global de ensamblados antes de permitir cargar tal código desde la configuración. Utilice ACL del directorio para proteger los directorios.

Se ha alcanzado el número máximo de sesiones seguras para un servicio

Cuando un servicio autentica correctamente un cliente y una sesión segura se establece con el servicio, el servicio sigue en contacto con la sesión hasta que el cliente la cancela o la sesión expira. Cada sesión establecida afecta al límite para el número máximo de sesiones simultáneas activas con un servicio. Cuando se alcanza este límite, se rechazan los clientes que intentan crear una nueva sesión con ese servicio hasta que una o más sesiones activas expiren o sean canceladas por un cliente. Un cliente puede tener varias sesiones con un servicio y cada una de esas sesiones afecta al límite.

Nota:
Al utilizar sesiones con estado, el párrafo anterior no se aplica. Para obtener más información sobre sesiones con estado, vea Cómo: Crear un token de contexto de seguridad para una sesión segura.

Para mitigar esto, establezca el límite para el número máximo de sesiones activas y la duración máxima para una sesión estableciendo la propiedad SecurityBindingElement de la clase SecurityBindingElement.

Vea también

Conceptos

Divulgación de información
Elevación de privilegio
Denegación de servicio
Ataques por repetición
Manipulación
Escenarios no admitidos

Otros recursos

Consideraciones de seguridad