Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
La elevación de privilegios resulta de conceder a un atacante permisos de autorización más allá de los concedidos inicialmente. Por ejemplo, un atacante con un conjunto de privilegios de "solo lectura" logra elevar este conjunto para incluir "lectura y escritura".
El STS de confianza debería firmar las notificaciones de tokens de SAML
Un token de lenguaje de marcado de aserciones de seguridad (SAML) es un token XML genérico que es el tipo predeterminado para los tokens emitidos. Un token SAML se puede construir mediante un servicio de token de seguridad (STS) en el que el servicio web final confía en un intercambio típico. Los tokens SAML contienen afirmaciones en declaraciones. Un atacante puede copiar las afirmaciones de un token válido, crear un nuevo token SAML y firmarlo con otro emisor. La intención es determinar si el servidor está validando emisores y, si no es así, usar la debilidad para construir tokens SAML que permitan privilegios más allá de los previstos por un STS de confianza.
La clase SamlAssertion verifica la firma digital contenida en un token SAML, y el valor predeterminado SamlSecurityTokenAuthenticator requiere que los tokens SAML sean firmados por un certificado X.509 que sea válido cuando la propiedad CertificateValidationMode de la clase IssuedTokenServiceCredential esté establecida en ChainTrust.
ChainTrust el modo por sí solo es insuficiente para determinar si el emisor del token SAML es de confianza. Los servicios que requieren un modelo de confianza más granular pueden usar políticas de autorización y cumplimiento para verificar el emisor de los conjuntos de declaraciones producidos por la autenticación de tokens expedidos. También pueden utilizar la configuración 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.
Cambio de identidad sin contexto de seguridad
Lo siguiente solo se aplica a WinFX.
Cuando se establece una conexión entre un cliente y un servidor, la identidad del cliente no cambia, excepto en una situación: después de abrir el cliente WCF, si se cumplen todas 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).Usa la autenticación de Windows.
No estableces explícitamente las credenciales.
Está llamando al servicio bajo el contexto de seguridad suplantado.
Si estas condiciones son verdaderas, la identidad usada para autenticar al cliente en el servicio podría cambiar (es posible que no sea la identidad suplantada, sino la identidad del proceso en su lugar) después de que se abra el cliente WCF. Esto ocurre porque la credencial de Windows usada para autenticar al cliente en el servicio se transmite con cada mensaje y la credencial usada para la autenticación se obtiene de la identidad de Windows del subproceso actual. Si la identidad de Windows del hilo actual cambia (por ejemplo, suplantando a otro llamador), la credencial vinculada al mensaje y utilizada para autenticar al cliente con el servicio también podría cambiar.
Si quieres tener un comportamiento determinista al usar la autenticación de Windows junto con la suplantación, debes establecer explícitamente la credencial de Windows o debes establecer un contexto de seguridad con el servicio. Para ello, use 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, solo debe usar una versión sincrónica de las operaciones de cliente al llamar al servicio. Si establece un contexto de seguridad de mensaje, no debe mantener abierta la conexión al servicio durante más tiempo que el período de renovación de sesión configurado, ya 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 hilo de contexto actual. Las credenciales se obtienen cuando se llama al Open método (o BeginOpen, para llamadas asincrónicas) del cliente o servicio. Tanto para las clases ServiceHost como para las ClientBase<TChannel>, los métodos Open y BeginOpen heredan de los métodos Open y BeginOpen de la clase CommunicationObject.
Nota:
Al usar el BeginOpen método , 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 usa la función de autoridad de seguridad local (LSA) LogonUser para autenticar a los usuarios por 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 caché los tokens que representan a los usuarios autenticados para aumentar el rendimiento. El mecanismo de almacenamiento en caché guarda los resultados de LogonUser para usos posteriores. Este mecanismo está deshabilitado de forma predeterminada; para habilitarlo, establezca la propiedad en CacheLogonTokenstrue, o use el atributo cacheLogonTokens de <userNameAuthentication>.
Puede establecer un período de vida (TTL) para los tokens almacenados en caché al establecer la CachedLogonTokenLifetime propiedad en un TimeSpan, o si usa el cachedLogonTokenLifetime atributo del userNameAuthentication elemento; el valor predeterminado es de 15 minutos. Tenga en cuenta que, mientras se almacena en caché un token, cualquier cliente que presente el mismo nombre de usuario y contraseña puede usar el token, incluso si la cuenta de usuario se elimina de Windows o si se ha cambiado su contraseña. Hasta que expire el TTL y el token se quite de la memoria caché, WCF permite que el usuario (posiblemente malintencionado) se autentique.
Para mitigar esto: reduzca la ventana de ataque estableciendo el valor cachedLogonTokenLifetime en el intervalo de tiempo más breve que necesiten los 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 cuando se utiliza el WSFederationHttpBinding junto con cualquiera de los enlaces proporcionados por el sistema que tienen un token emitido como tipo de credencial de cliente.
Esto también ocurre cuando se crean enlaces personalizados mediante uno de los métodos siguientes:
Para mitigar 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 usa un certificado diferente al previsto por el cliente.
En determinadas condiciones, un cliente puede firmar digitalmente un mensaje con un certificado X.509 y hacer que el servicio recupere un certificado diferente al previsto.
Esto puede ocurrir en 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 simplemente hace referencia al certificado mediante 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 del firmante, pero no es el que el cliente pretende usar. 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 usar IssuerSerial.