Elevación de privilegios
La elevación de privilegios es el resultado de 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 de SAML y el SamlSecurityTokenAuthenticator predeterminado necesita que los tokens de SAML estén firmados por un certificado X.509 que sea válido cuando el CertificateValidationMode de la clase IssuedTokenServiceCredential se establezca en ChainTrust. El modo ChainTrust solo no es suficiente para determinar si el emisor del token de 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 más información, consulte 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 WinFX.
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 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
falseen caso de seguridad de mensajes o se utiliza un transporte incapaz de establecer sesiones de seguridad en caso de seguridad de transporte. HTTP 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 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 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<TChannel>, los métodos Open y BeginOpen heredan de los métodos Open y BeginOpen de la clase CommunicationObject.
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 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 true o utilice el atributo cacheLogonTokens de <userNameAuthentication>.
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 la 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, 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.