Elevación de privilegio
La elevación de privilegios resulta al proporcionar permisos de autorización a un atacante más allá de aquéllos concedidos inicialmente. Por ejemplo, un atacante con un conjunto de privilegios de permisos de "solo lectura" eleva de algún modo el conjunto para incluir la "lectura y escritura".
El STS de confianza debería firmar las notificaciones de tokens de SAML
Un token del lenguaje de marcado de aserción de seguridad (SAML) es un token XML genérico que es del tipo predeterminado para tokens emitidos. Un servicio de tokens de seguridad (STS) puede construir un token SAML en el que confíe el servicio web final en un intercambio típico. Los tokens SAML contienen las notificaciones en declaraciones. Un atacante puede copiar las notificaciones desde un token válido, crear un nuevo token SAML y firmarlo con un emisor diferente. El objetivo es determinar si el servidor está validando a los emisores y, si no, utilizar esa debilidad para construir tokens SAML que concedan privilegios más allá de los proporcionados por un STS de confianza.
La clase SamlAssertion comprueba la firma digital contenida dentro de un token SAML y el SamlSecurityTokenAuthenticator predeterminado requiere que los tokens SAML sean firmados mediante un certificado X.509 que es válido cuando la propiedad CertificateValidationMode de la clase IssuedTokenServiceCredential está establecida en ChainTrust. El modo ChainTrust por sí solo no es suficiente para determinar si el emisor del token SAML es de confianza. Los servicios que requieren un modelo de confianza más específico pueden usar directivas de autorización y cumplimiento para comprobar el emisor de los conjuntos de notificaciones producidos mediante la autenticación de tokens emitidos o usar los valores de validación X.509 en IssuedTokenServiceCredential para restringir el conjunto de certificados de firma permitidos. Para obtener más información, vea Administración de notificaciones y autorización con el modelo de identidad y Federación y tokens emitidos.
Intercambio de identidad sin un contexto de seguridad
Lo siguiente solo se aplica a .NET Framework 3.0.
Cuando se establece una conexión entre un cliente y servidor, la identidad del cliente no cambia, excepto en una situación: una vez abierto el cliente de WCF, si se cumplen las condiciones siguientes:
Se desactivan los procedimientos para establecer un contexto de seguridad (mediante una sesión de seguridad de transporte o sesión de seguridad de mensajes) (la propiedad EstablishSecurityContext se establece en false en caso de seguridad de mensajes o se utiliza un transporte incapaz de establecer sesiones de seguridad en caso de seguridad de transporte. HTTPS es un ejemplo de dicho transporte).
Está utilizando la autenticación de Windows.
No establece explícitamente la credencial.
Está llamando al servicio bajo el contexto de seguridad suplantado.
Si estas condiciones se cumplen, la identidad utilizada para autenticar el cliente en el servicio podría cambiar (podría no ser la identidad suplantada, sino, en su lugar, la identidad del proceso) una vez abierto el cliente de WCF. Esto ocurre porque la credencial de Windows utilizada para autenticar el cliente en el servicio se transmite con cada mensaje, y la credencial utilizada para la autenticación se obtiene a partir de la identidad de Windows del subproceso actual. Si la identidad de Windows del subproceso actual cambia (por ejemplo, suplantando a un llamador diferente), la credencial adjunta al mensaje y utilizada para autenticar el cliente en el servicio también podría cambiar.
Si desea tener un comportamiento determinista al utilizar la autenticación de Windows junto con la suplantación, debe establecer explícitamente la credencial de Windows o debe establecer un contexto de seguridad con el servicio. Para ello, utilice una sesión de seguridad de mensajes o una sesión de seguridad de transporte. Por ejemplo, el transporte net.tcp puede proporcionar una sesión de seguridad de transporte. Además, debe utilizar solo una versión sincrónica de operaciones de cliente al llamar al servicio. Si establece un contexto de seguridad de mensajes, no debería mantener abierta la conexión con el servicio más tiempo del periodo de renovación de sesión configurado, puesto que la identidad también puede cambiar durante el proceso de renovación de sesión.
Captura de credenciales
Lo siguiente se aplica a .NET Framework versión 3.5 y versiones posteriores.
Las credenciales utilizadas por el cliente o el servicio se basan en el subproceso de contexto actual. Las credenciales se obtienen cuando se llama al método Open (o BeginOpen, para las llamadas asincrónicas) del cliente o servicio. Para las clases ServiceHost y ClientBase, los métodos Open y BeginOpen heredan de los métodos Open y BeginOpen de la clase CommunicationObject.
.gif "Aa751843.note(es-es,VS.100).gif") Nota: |
|---|
| Al utilizar el método BeginOpen, no se puede garantizar que las credenciales capturadas sean las credenciales del proceso que llama al método. |
Las cachés de tokens permiten la repetición mediante datos obsoletos
WCF utiliza la función LogonUser de autoridad de seguridad local (LSA) para autenticar a los usuarios mediante nombre de usuario y contraseña. Dado que la función de inicio de sesión es una operación costosa, WCF le permite almacenar en memoria caché tokens que representan a usuarios autenticados para aumentar el rendimiento. El mecanismo de almacenamiento en caché guarda los resultados de LogonUser para los usos posteriores. Este mecanismo está deshabilitado de forma predeterminada; para habilitarlo, establezca la propiedad CacheLogonTokens en trueo utilice el atributo cacheLogonTokens del userNameAuthentication element.
Puede establecer un período de vida (TTL) para los tokens almacenados en memoria caché estableciendo la propiedad CachedLogonTokenLifetime en TimeSpan o utilizar el atributo cachedLogonTokenLifetime del elemento userNameAuthentication; el valor predeterminado es de 15 minutos. Tenga en cuenta que mientras un token esté almacenado en memoria caché, cualquier cliente que presente el mismo nombre de usuario y contraseña podrá utilizar el token, aunque la cuenta de usuario se elimine de Windows o se haya cambiado su contraseña. Hasta que el TTL expire y el token se elimine de la caché, WCF permite al usuario (posiblemente malintencionado) autenticarse.
Para paliar esto: disminuya la ventana de ataque estableciendo el valor de cachedLogonTokenLifetime en el intervalo de tiempo más corto que necesiten sus usuarios.
Autorización de tokens emitidos: restablecimiento de la expiración a un valor mayor
Bajo ciertas condiciones, la propiedad ExpirationTime del AuthorizationContext puede establecerse en un valor inesperadamente mayor (el valor del campo MaxValue menos un día o el 20 de diciembre de 9999).
Esto ocurre al utilizar el WSFederationHttpBinding y cualquiera de los enlaces proporcionados por el sistema que tengan un token emitido como el tipo de credencial de cliente.
Esto también ocurre al crear enlaces personalizados utilizando uno de los siguientes métodos:
Para paliar esto, la directiva de autorización debe comprobar la acción y la hora de expiración de cada directiva de autorización.
El Servicio utiliza un certificado diferente del que el cliente pretendía
Bajo ciertas condiciones, un cliente puede firmar digitalmente un mensaje con un certificado X.509 y hacer que el servicio recupere un certificado diferente del deseado.
Esto puede suceder bajo las siguientes circunstancias:
El cliente firma digitalmente un mensaje mediante un certificado X.509 y no adjunta el certificado X.509 al mensaje, sino que solo hace referencia al certificado utilizando su identificador de clave de sujeto.
El equipo del servicio contiene dos o más certificados con la misma clave pública, pero contienen información diferente.
El servicio recupera un certificado que coincide con el identificador de clave de sujeto (SKI), pero no es el que el cliente pensaba utilizar. Cuando WCF recibe el mensaje y comprueba la firma, WCF asigna la información del certificado X.509 imprevisto a un conjunto de notificaciones que son diferentes y potencialmente elevadas de lo que el cliente esperaba.
Para mitigar esto, haga referencia al certificado X.509 de otra manera, como, por ejemplo, mediante IssuerSerial.
Vea también
Conceptos
Divulgación de información
Denegación de servicio
Ataques por repetición
Manipulación
Escenarios no admitidos