Élévation de privilège

2025-06-20

L’élévation de privilèges résulte de l’octroi d’autorisations d’attaquant au-delà de celles initialement accordées. Par exemple, un attaquant disposant d'un ensemble de privilèges « lecture seule » élève d'une manière ou d'une autre cet ensemble pour inclure « lecture et écriture ».

Un STS approuvé doit signer des revendications de jeton SAML

Un jeton SAML (Security Assertions Markup Language) est un jeton XML générique qui est le type par défaut pour les jetons émis. Un jeton SAML peut être construit par un service STS (Security Token Service) approuvé par le service Web final dans un échange classique. Les jetons SAML contiennent des assertions dans des déclarations. Un attaquant peut copier les revendications à partir d’un jeton valide, créer un jeton SAML et le signer avec un autre émetteur. L’intention est de déterminer si le serveur valide les émetteurs et, si ce n’est pas le cas, utilisez la faiblesse pour construire des jetons SAML qui autorisent des privilèges au-delà de ceux prévus par un STS approuvé.

La classe SamlAssertion vérifie la signature numérique contenue dans un jeton SAML, et par défaut, SamlSecurityTokenAuthenticator exige que les jetons SAML soient signés par un certificat X.509 valide lorsque la classe CertificateValidationMode est définie sur IssuedTokenServiceCredential. ChainTrust le mode seul est insuffisant pour déterminer si l’émetteur du jeton SAML est approuvé. Les services qui nécessitent un modèle d’approbation plus granulaire peuvent utiliser des stratégies d’autorisation et d’application pour vérifier l’émetteur des ensembles de revendications générés par l’authentification par jeton émis ou utiliser les paramètres de validation X.509 sur IssuedTokenServiceCredential lesquels limiter l’ensemble de certificats de signature autorisés. Pour plus d’informations, consultez Gestion des revendications et des autorisations avec le modèle d'identité et Fédération et jetons émis.

Changement d’identité sans contexte de sécurité

Les éléments suivants s’appliquent uniquement à WinFX.

Lorsqu’une connexion est établie entre un client et un serveur, l’identité du client ne change pas, sauf dans une situation : après l’ouverture du client WCF, si toutes les conditions suivantes sont remplies :

Les procédures permettant d’établir un contexte de sécurité (à l’aide d’une session de sécurité de transport ou d’une session de sécurité de message) sont désactivées ( laEstablishSecurityContext propriété est définie false en cas de sécurité des messages ou de transport non capable d’établir des sessions de sécurité est utilisée dans le cas de sécurité du transport. HTTPS est un exemple de ce type de transport).
Vous utilisez l’authentification Windows.
Vous ne définissez pas explicitement les données d'authentification.
Vous appelez le service sous un contexte de sécurité simulé.

Si ces conditions sont remplies, l’identité utilisée pour authentifier le client auprès du service peut changer (il peut ne pas s’agir de l’identité empruntée, mais de l’identité du processus à la place) après l’ouverture du client WCF. Cela se produit, car les informations d’identification Windows utilisées pour authentifier le client auprès du service sont transmises avec chaque message, et les informations d’identification utilisées pour l’authentification sont obtenues à partir de l’identité Windows du thread actuel. Si l’identité Windows du thread actuel change (par exemple, en empruntant l’identité d’un autre appelant), les informations d’identification attachées au message et utilisées pour authentifier le client auprès du service peuvent également changer.

Si vous souhaitez avoir un comportement déterministe lors de l’utilisation de l’authentification Windows avec l’emprunt d’identité, vous devez définir explicitement les informations d’identification Windows ou établir un contexte de sécurité avec le service. Pour ce faire, utilisez une session de sécurité de message ou une session de sécurité de transport. Par exemple, le transport net.tcp peut fournir une session de sécurité de transport. En outre, vous devez utiliser uniquement une version synchrone des opérations clientes lors de l’appel du service. Si vous établissez un contexte de sécurité des messages, vous ne devez pas conserver la connexion au service ouverte plus longtemps que la période de renouvellement de session configurée, car l’identité peut également changer pendant le processus de renouvellement de session.

Capture des identifiants

Les éléments suivants s’appliquent à .NET Framework 3.5 et aux versions suivantes.

Les informations d’identification utilisées par le client ou le service sont basées sur le thread de contexte actuel. Les informations d’identification sont obtenues lorsque la Open méthode (ou BeginOpen, pour les appels asynchrones) du client ou du service est appelée. Pour les deux classes ServiceHost et ClientBase<TChannel>, les méthodes Open et BeginOpen héritent des méthodes Open et BeginOpen de la classe CommunicationObject.

Remarque

Lorsque vous utilisez la BeginOpen méthode, les informations d’identification capturées ne peuvent pas être garanties comme les informations d’identification du processus qui appelle la méthode.

Les caches de jetons autorisent la relecture à l’aide de données obsolètes

WCF utilise la fonction l’autorité de sécurité locale (LSA) LogonUser pour authentifier les utilisateurs par nom d’utilisateur et mot de passe. Étant donné que la fonction d’ouverture de session est une opération coûteuse, WCF vous permet de mettre en cache des jetons qui représentent des utilisateurs authentifiés afin d’augmenter les performances. Le mécanisme de mise en cache enregistre les résultats de LogonUser pour des utilisations ultérieures. Ce mécanisme est désactivé par défaut ; pour l’activer, définissez la propriété CacheLogonTokenstrue ou utilisez l’attribut cacheLogonTokens<userNameAuthentication>.

Vous pouvez définir une durée de vie (TTL) pour les jetons mis en cache en définissant la CachedLogonTokenLifetime propriété sur un TimeSpan, ou utiliser l’attribut cachedLogonTokenLifetime de l’élément userNameAuthentication ; la valeur par défaut est de 15 minutes. Notez que si un jeton est mis en cache, tout client qui présente le même nom d’utilisateur et mot de passe peut utiliser le jeton, même si le compte d’utilisateur est supprimé de Windows ou si son mot de passe a été modifié. Jusqu'à l'expiration de la durée de vie et que le jeton soit supprimé du cache, WCF permet à l'utilisateur (éventuellement malveillant) de s'authentifier.

Pour atténuer ce problème : réduisez la fenêtre d’attaque en définissant la cachedLogonTokenLifetime valeur sur l’intervalle de temps le plus court dont vos utilisateurs ont besoin.

Autorisation de jeton émis : l'expiration réinitialisée à une grande valeur

Dans certaines conditions, la ExpirationTime propriété de AuthorizationContext peut être définie sur une valeur plus grande que prévu (la valeur du champ MaxValue moins un jour ou le 20 décembre 9999).

Cela se produit lors de l'utilisation du WSFederationHttpBinding et des liaisons fournies par le système qui ont un jeton émis comme type d'informations d'identification du client.

Cela se produit également lorsque vous créez des liaisons personnalisées à l’aide de l’une des méthodes suivantes :

Pour atténuer ce problème, la stratégie d’autorisation doit vérifier l’action et l’heure d’expiration de chaque stratégie d’autorisation.

Le service utilise un certificat différent de celui que le client avait anticipé.

Dans certaines conditions, un client peut signer numériquement un message avec un certificat X.509 et faire en sorte que le service récupère un certificat différent de celui prévu.

Cela peut se produire dans les circonstances suivantes :

Le client signe numériquement un message à l’aide d’un certificat X.509 et n’attache pas le certificat X.509 au message, mais référence simplement le certificat à l’aide de son identificateur de clé d’objet.
L’ordinateur du service contient deux certificats ou plus avec la même clé publique, mais ils contiennent des informations différentes.
Le service récupère un certificat qui correspond à l’identificateur de clé d’objet, mais il n’est pas celui que le client a prévu d’utiliser. Lorsque WCF reçoit le message et vérifie la signature, WCF mappe les informations dans le certificat X.509 involontaire à un ensemble de revendications qui sont différentes et potentiellement élevées de ce que le client attendait.

Pour atténuer ce problème, référencez le certificat X.509 d’une autre façon, comme l’utilisation IssuerSerial.

Partager via