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 deSPNegoo negociaciónSSL.IssuedCookieLifetime: controla la duración de
SecurityContextTokensque el servidor emite trasSPNegoo una negociaciónSSL. El servidor almacena en memoria caché losSecurityContextTokens 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 activa 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 patrón 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 esto, 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 el procedimiento para usar el visor de eventos a fin de ver y administrar registros de eventos, consulte Visor de eventos. Para obtener más información, consulte Auditoría.
Las implementaciones no válidas de IAuthorizationPolicy pueden hacer que el servicio deje de responder
Las llamadas al método Evaluate en una implementación defectuosa de la interfaz IAuthorizationPolicy puede hacer que el servicio deje de responder.
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 del servicio. WCF no hace ninguna distinción entre el código de la aplicación y el código externo que se conecta mediante 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 del token de Kerberos. También es posible que deba aumentar el tamaño máximo del mensaje WCF para alojar un token de Kerberos más grande.
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 de forma automática 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 impacto es que los servicios WCF puede producir un error al abrir dominios con 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 se va a usar mediante un criterio de búsqueda más preciso en <serviceCredentials>. 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, consulte Inscripción automática de certificados 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 notificaciones necesarias y opcionales en código y archivos de configuración para los tokens emitidos de 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. Use listas de control de acceso (ACL) de archivo para proteger los archivos de configuración. WCF necesita que el código esté en el directorio de la aplicación o en la caché global de ensamblados antes de que dicho código se pueda cargar 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
Cuando se usan sesiones con estado, el párrafo anterior no se aplica. Para obtener más información sobre sesiones con estado, consulte Procedimiento para 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.