¿Le resultó útil esta página?
Sus comentarios sobre este contenido son muy importantes. Háganos saber su opinión.
¿Tiene comentarios adicionales?
Caracteres restantes: 1500
Exportar (0) Imprimir
Expandir todo

Consideraciones de seguridad

Windows Identity Foundation

Consideraciones de privacidad

Los desarrolladores que crean aplicaciones que usan Windows® Identity Foundation (WIF) deberían crear sus propias declaraciones de privacidad específicas de la aplicación, porque la declaración de privacidad de WIF no cubre estas aplicaciones. La declaración de privacidad de WIF se puede encontrar en Declaración de privacidad de Windows Vista y Declaración de privacidad de Windows 7

Consideraciones de seguridad de STS y RP

Consideraciones de seguridad de STS

Un Security Token Service (STS) debería tomar las siguientes precauciones de seguridad:

  • Validar la dirección e identidad del valor en la propiedad AppliesTo del RequestSecurityToken entrante.

  • Cifrar las claves de prueba de token SAML para el RP deseado al emitir tokens. El RP debería rechazar los tokens cuyas claves de prueba no puede descifrar.

  • Cifrar claves de prueba simétricas. Esta es la configuración predeterminada de WIF y se puede establecer en EncryptingCredentials.

  • Tener en cuenta las amenazas de la colaboración, por ejemplo dos RP malintencionados o cuya seguridad esté en peligro que cooperan para realizar el seguimiento de un usuario o recopilar la información privada de un usuario.

  • Elegir la entropía combinada para las claves simétricas.

  • Firmar los tokens emitidos. De forma predeterminada, un STS compilado con WIF firma los tokens emitidos mediante SHA-256.

  • Tratar los valores del RequestSecurityToken entrante como una entrada que no es de confianza. Por ejemplo, si un valor se utiliza como clave de búsqueda de base de datos en GetOutputClaimsIdentity, el valor se podría utilizar en un ataque de inyección de SQL. Un usuario malintencionado podría hacer esto modificando el parámetro wrealm de la cadena de consulta que se envía a un STS de ASP.NET.

  • Mantener una memoria caché de las Tarjetas de información que emite. De esta manera, cuando recibe una solicitud para emitir un token, puede comprobar que la solicitud contiene una referencia a una Tarjeta de información conocida y actual. Si la referencia se hace a una Tarjeta de información desconocida, o a una Tarjeta de información que ha expirado, el STS puede administrar la solicitud en consecuencia.

  • Administrar las excepciones de forma segura. Una excepción podría contener pequeños fragmentos de código, seguimientos de pila y rutas de acceso de archivos que podrían ser útiles para los atacantes. Un modo de mitigar esto es escribir los datos de excepción en una base de datos y simplemente notificar un error interno del servidor, incluido el identificador del registro de base de datos (sin identificarlo como tal).

  • No se deberían utilizar sufijos de nombre de dominio conocidos como "com", "net", "org", etc., como nombres de host para el STS si se utilizan en una intranet. Esto podría dar pie a que el RP sufra ataques de suplantación de identidad (phishing) a través del parámetro wreply del mensaje SignOutCleanupRequest de WS-Trust. Por ejemplo, "fabrikam.com" se consideraría como una subred válida del emisor "com" y atravesaría el filtro de validación de wreply en el RP. Entonces el cliente podría ser redirigido a un sitio malintencionado en esta dirección URL cuando el RP ejecute el parámetro wreply. La probabilidad de este tipo de ataque es baja porque la solicitud debe proceder de un equipo que ya se encuentre en la misma intranet, pero todavía debería seguir estos consejos para mitigar el riesgo.

Consideraciones de seguridad de RP

Una aplicación de usuario de confianza (RP) debería tomar las siguientes precauciones de seguridad:

  • Validar las direcciones en la restricción de la audiencia del token de seguridad entrante para asegurarse de que el token tiene como destino el usuario de confianza. WIF lo hace de forma predeterminada para los tokens que no contienen una clave de prueba de posesión.

  • Validar el emisor de tokens.

  • Comprobar que el emisor es de confianza para emitir las notificaciones en el token.

  • Tratar las notificaciones en el token como entrada que no es de confianza.

Las aplicaciones de RP deben comprobar el emisor de tokens

Las aplicaciones de usuario de confianza deberían comprobar el emisor de tokens antes de utilizar tokens y las notificaciones que contienen. Para los tokens firmados utilizando un certificado X509, el emisor se puede comprobar de varias maneras, por ejemplo con la confianza de par o cadena. Los tokens emitidos a través de tarjetas personales se firman utilizando una clave RSA autoemitida, que normalmente se acepta tal cual. Las configuraciones de directiva de la aplicación deben comprobar que los emisores son de confianza para realizar las notificaciones incluidas en los tokens que emiten. De forma predeterminada, WIF exige firmar los tokens emitidos y comprueba la firma del emisor.

Disponibilidad de los tokens de arranque

Un token de arranque es el token original utilizado para autenticar el cliente. En las versiones anteriores de WIF no había ninguna manera coherente de que la aplicación de RP tuviera acceso a este token. Una vez extraídas las notificaciones, se destruía este token.

En la versión actual, el token de arranque se conserva y queda disponible a través de ClaimsPrincipal y se puede obtener acceso a él utilizando la propiedad BootstrapToken. Esto es útil para las aplicaciones que deben implementar el escenario de ActAs.

En ASP.NET o WCF, puede tener acceso al token de arranque como sigue:


// Get the Bootstrap Token SecurityToken bootstrapToken = null;

IClaimsPrincipal claimsPrincipal = Thread.CurrentPrincipal as IClaimsPrincipal; if ( claimsPrincipal != null ) { IClaimsIdentity claimsIdentity = (IClaimsIdentity)claimsPrincipal.Identity; bootstrapToken = claimsIdentity.BootstrapToken; }

ProofEncryption

ProofEncryption se utiliza para comunicar información sobre cómo cifrar el token de prueba solicitado y cómo cifrar la entropía en la Solicitud de respuesta del token de seguridad (RSTR). Está pensado para los casos en los que el transporte o el mensaje no está utilizando una característica de seguridad. Si se utiliza cuando el transporte o el mensaje está utilizando un tipo de seguridad, puede crear un doble cifrado del token y la entropía; es decir, una vez en el nivel del token y la entropía y otra vez en el nivel del mensaje y el transporte. Por ejemplo, Windows Communication Foundation (WCF) le permite elegir un tipo de seguridad para el canal de comunicación entre el cliente y el STS. Por consiguiente, en este caso, ProofEncryption se puede establecer en null sin ningún riesgo.

Utilizar tokens de arranque al utilizar ActAs con el token de nombre de usuario

Al utilizar ActAs con un token de nombre de usuario, debe tener cuidado de no filtrar la contraseña del cliente. WCF expone el objeto UserNameSecurityToken en la propiedad OperationContext.Current.IncomingMessageProperties.Security.IncomingSupportingTokens cuando se deshabilita la conversación segura. Si este token se utiliza directamente con WSTrustChannel o FederatedClientCredentials, la contraseña del cliente quedará expuesta.

Para evitar esto, los clientes deberían utilizar siempre los tokens de arranque de BootstrapToken. WIF anula la contraseña al guardar los tokens de arranque.

El parámetro wctx no debería contener información confidencial

Un STS que cumpla con las especificaciones debería conservar el valor del parámetro wctx y devolverlo al RP tras la redirección. Un RP utiliza este parámetro para conservar el estado después de redirigir un cliente al STS. El propio RP debe proteger esta información, ya que WIF mandará el parámetro wctx en texto legible. Un STS también podría exponer accidentalmente la información de este parámetro a través de los registros de mensajes.

Las transformaciones que reemplazan ProtectedDataCookieTransform deben proporcionar cifrado

WIF, de forma predeterminada, ofrece el objeto ProtectedDataCookieTransform que proporciona cifrado para los tokens de sesión. Si decide reemplazarlo por una transformación personalizada, asegúrese de que la transformación personalizada proporciona la capacidad de cifrado.

Falsificación de solicitudes entre sitios

WIF utiliza cookies al autenticar un cliente en un sitio web para mantener una sesión autenticada. Puede que existan cookies para el dominio del STS (para el inicio de sesión único en varios sitios web) o para el dominio del usuario de confianza (para el inicio de sesión único dentro de las páginas de una aplicación federada). Este uso de cookies corre el riesgo de que se produzca una falsificación de solicitudes entre sitios, en la que las cookies se utilizan para autenticar y realizar alguna acción cuando el usuario visita una página web de un tercero con contenido malintencionado. Los desarrolladores de STS y RP deberían ser conscientes de este riesgo e implementar las medidas adecuadas.

WindowsClaimsIdentity.CertificateLogon no requiere que una raíz con confianza de Active Directory emita un certificado

En sistemas operativos anteriores a Windows Vista y Windows Server 2008, CertificateLogon crea una identidad de Windows basada solamente en SubjectAltName en el certificado. No requiere que una raíz con confianza de Active Directory emita un certificado. Esto posibilita la suplantación de cualquier usuario del dominio utilizando un certificado que se encadena hasta una raíz en la que confía el equipo local, pero no Active Directory.

también llama al método CertificateLogon, de modo que surge el mismo problema si una aplicación de usuario de confianza se ejecuta en un sistema operativo anterior a Windows Vista y Windows Server 2008 y llama al método CertificateLogon y pasa un certificado desde el cliente.

Consideraciones de seguridad de WS-FAM

Un sitio web malintencionado puede cerrar la sesión de un usuario en el RP

Los mensajes SignOutCleanup y SignOut definidos en la especificación de WS-Federation no exigen la autenticación. Esto hace posible que un sitio web malintencionado (RP) cierre la sesión de un usuario en un STS redirigiendo a los usuarios al STS con un mensaje SignOut. Una posible solución es hacer que el STS omita el mensaje SignOut/SignOutCleanup de WS-Federation y, en su lugar, sirva al usuario una página que le ofrezca la opción de cerrar la sesión.

Para un RP que utilice WS-FAM, aunque no se autentica el mensaje de SignOutCleanup, es posible que un sitio web malintencionado cree un vínculo que envíe un mensaje SignOutCleanup desde un usuario autenticado en el RP. El evento OnSigningOut de WS-FAM se invoca antes de que se cierre realmente la sesión del usuario, y es posible bloquear la acción o tomar algunas otras medidas en ese momento. WIF realiza la validación en el parámetro wreply del mensaje para bloquear cualquier ataque de suplantación de identidad (phishing) que redirija al usuario a un sitio falso después de cerrar la sesión en el RP. El usuario solo se redirige a wreply si la dirección URL está en el mismo dominio que el emisor. Si no lo está, el usuario simplemente se redirige otra vez al emisor.

Recursos nativos y archivos estáticos no protegidos por WS-FAM de forma predeterminada

Los recursos nativos y archivos estáticos, por ejemplo los que tienen extensiones .TXT, .GIF, .HTML y .XML, de forma predeterminada, son devueltos por IIS sin invocar a ASP.NET, de modo que WIF no los protege. De forma predeterminada, FedUtil y las plantillas de proyecto de Visual Studio proporcionadas por ASP.NET agregan el Módulo de autenticación federado al archivo app.config o web.config de la aplicación, de forma que solo habilita la protección de los recursos administrados. Esto es así por diseño. Para habilitar la protección de los recursos nativos, quite los atributos preCondition = “managedHandler” de los elementos <system.webServer>/<modules> que agregan WSFederationAuthenticationModule y SessionAuthenticationModule.

Tenga en cuenta que mientras depura sus aplicaciones hospedadas en web mediante el servidor web integrado de Visual Studio, se omite el atributo preCondition="managedHandler" y se protegen los recursos administrados y nativos. Sin embargo, si tiene acceso a la aplicación web a través de IIS, se tiene en cuenta el atributo de condición previa y, por lo tanto, WS-FAM solo protege los recursos administrados.

Mostrar:
© 2015 Microsoft