Bulletin de sécurité Microsoft MS11-100 - Critique

Une atténuation fait référence à un paramètre, une configuration générale ou à des préférences existant dans un état par défaut qui pourraient diminuer l'impact de l'exploitation d'une vulnérabilité. Les facteurs atténuants suivants peuvent être utiles, selon votre situation :

• Par défaut, IIS n'est activé sur aucun système d'exploitation Windows.
• Les sites qui rejettent les types de contenu HTTP application/x-www-form-urlencoded ou multipart/form-data ne sont pas affectés par cette vulnérabilité.
• Par défaut, ASP.NET n'est pas installé lorsque .NET Framework est installé. Seuls les clients qui ont installé et activé manuellement ASP.NET peuvent être concernés par ce problème.

Une solution de contournement fait référence à une modification de paramètre ou de configuration qui ne corrige pas la vulnérabilité sous-jacente mais qui pourrait contribuer à bloquer certains vecteurs d'attaque connus jusqu'à ce que la mise à jour soit appliquée. Microsoft a testé les solutions de contournement suivantes et indique le cas échéant si une solution réduit certaines fonctionnalités :

• Solution de contournement basée sur la configuration

  La solution de contournement suivante configure la limite de taille de requête maximale qu'ASP.NET acceptera d'un client. La diminution de cette taille diminuera la vulnérabilité du serveur ASP.NET à une attaque de déni de service.

  Remarque : Veillez à sauvegarder votre configuration avant toute modification.

  Cette valeur de configuration peut être appliquée de manière globale à tous les sites ASP.NET sur un serveur en ajoutant l'entrée à la racine web.config ou applicationhost.config. Cette configuration peut également être limitée à un site ou une application spécifique en l'ajoutant au fichier web.config correspondant. Pour plus d'informations sur la configuration ASP.NET, veuillez vous reporter à l'article MSDN « Vue d'ensemble de la configuration ASP.NET ».

  1. Si votre application utilise ViewState, ajoutez la configuration suivante dans le fichier de configuration ASP.NET approprié pour limiter à 200 Ko la taille maximale de requête qu'ASP.NET acceptera d'un client.

     <configuration>
  <system.web>
  <httpRuntime maxRequestLength="200"/>
  </system.web>
</configuration>

  2. Si votre application n'utilise pas ASP.NET ViewState, ajoutez la configuration suivante dans le fichier de configuration ASP.NET approprié pour limiter à 20 Ko la taille maximale de requête qu'ASP.NET acceptera d'un client.

     <configuration>
  <system.web>
  <httpRuntime maxRequestLength="20"/>
  </system.web>
</configuration>

  Pour plus d'informations sur l'option de configuration maxRequestLength, veuillez vous reporter à l'article MSDN « httpRuntime, élément ».

  Remarque : L'augmentation des limites de taille de la chaîne de requête HTTP par défaut et des en-têtes de requête augmentera les possibilités pour le serveur d'être affecté par le problème de déni de service décrit dans cet Avis. Pour plus d'informations sur la définition de ces limites, veuillez vous reporter à l'article consacré aux paramètres de Registre http.sys pour IIS (en anglais).

  Impact de cette solution de contournement : Les requêtes client qui dépassent la valeur maxRequestLength configurée entraîneront une exception ConfigurationErrorsException côté serveur et un statut d'erreur HTTP sera renvoyé au client. Les limites configurées précédemment doivent être utilisées comme référence et peuvent être ajustées pour éviter des échecs d'application. La configuration d'une valeur maxRequestLength inférieure réduit également la possibilité pour le serveur d'être affecté par ce déni de service particulier. Les applications qui acceptent les téléchargements de fichier client et celles qui génèrent une taille de ViewState importante représentent des exemples d'applications pouvant être concernées par cette solution de contournement.

  Après avoir appliqué cette solution de contournement, la défaillance de requête client suivante peut s'afficher dans le journal des événements de l'application.

  Code d'événement : 3004
Message d'événement : La taille du postage a dépassé les limites autorisées.
Information d'exception :
    Type d'exception : HttpException
    Message d'exception : Longueur maximale de la demande dépassée.
   à System.Web.HttpRequest.GetEntireRawContent()
   à System.Web.HttpRequest.FillInFormCollection()
   à System.Web.HttpRequest.get_Form()
   à System.Web.HttpRequest.get_HasForm()
   à System.Web.UI.Page.GetCollectionBasedOnMethod(Boolean dontReturnNull)
   à System.Web.UI.Page.DeterminePostBackMode()
   à System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

  La défaillance de requête peut également entraîner l'entrée suivante dans un fichier journal IIS.

  #Fields: s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken

127.0.0.1 POST /webSite/Default.aspx - 80 - 127.0.0.1 - 500 0 0 1268

  Suppression de la solution de contournement : Pour annuler la solution de contournement, supprimez les sections de configuration qui ont été ajoutées dans cette solution de contournement ou revenez à une sauvegarde de la configuration effectuée avant les solutions de contournement.

Quelle est la portée de cette vulnérabilité ? 
Il s'agit d'une vulnérabilité de déni de service. Cette vulnérabilité permet à un attaquant non authentifié de dégrader les performances d'un site ASP.NET en créant une condition de déni de service.

Quelle est la cause de cette vulnérabilité ? 
Cette vulnérabilité existe en raison de la façon dont ASP.NET hache les requêtes spécialement conçues et insère ces données dans une table de hachage, entraînant ainsi une collision de hachage. Lorsque de nombreuses collisions s'enchaînent, les performances de la table de hachage sont considérablement dégradées, entraînant ainsi une condition de déni de service.

Que pourrait faire un attaquant en exploitant cette vulnérabilité ? 
Un attaquant pourrait utiliser cette vulnérabilité pour générer une attaque de déni de service et interrompre la disponibilité de sites utilisant ASP.NET.

Comment un attaquant pourrait-il exploiter cette vulnérabilité ? 
Un attaquant non authentifié pourrait envoyer un petit nombre de requêtes ASP.NET spécialement conçues à un site ASP.NET affecté, générant ainsi une condition de déni de service.

Quels sont les systèmes les plus exposés à cette vulnérabilité ? 
Les systèmes directement connectés à Internet avec ASP.NET sont les plus exposés à cette vulnérabilité. De plus, les sites Web internes utilisant l'authentification par formulaires ASP.NET sont également exposés à cette vulnérabilité.

Que fait cette mise à jour ? 
Cette mise à jour corrige cette vulnérabilité en modifiant la façon dont .NET Framework traite des requêtes spécialement conçues.

Lors de la parution de ce Bulletin de sécurité, cette vulnérabilité avait-elle été révélée publiquement ? 
Oui. Cette vulnérabilité a été révélée publiquement. Elle a reçu le numéro « Common Vulnerability and Exposure » CVE-2011-3414.

Lors de la parution de ce Bulletin de sécurité, Microsoft avait-il été informé d'une éventuelle exploitation de cette vulnérabilité ? 
Non. Lors de la première publication de ce Bulletin, Microsoft n'avait reçu aucune information faisant état d'une utilisation de cette vulnérabilité dans le but d'attaquer des clients.

Dans quelle mesure s'agit-il d'un problème affectant l'ensemble de l'industrie ?
Les attaques qui ciblent ce type de vulnérabilité sont généralement connues sous le nom d'attaques par collision de hachage. Ces attaques ne sont pas spécifiques aux technologies Microsoft et affectent d'autres fournisseurs de logiciels de service Web. Les clients doivent contacter leurs fournisseurs de plate-forme Web pour obtenir des conseils ou des mises à jour.

Une atténuation fait référence à un paramètre, une configuration générale ou à des préférences existant dans un état par défaut qui pourraient diminuer l'impact de l'exploitation d'une vulnérabilité. Les facteurs atténuants suivants peuvent être utiles, selon votre situation :

• Cette vulnérabilité ne permet pas à un attaquant d'exécuter du code ou d'élever directement ses privilèges, mais elle pourrait servir à produire des informations susceptibles de donner à l'attaquant les moyens de compromettre davantage les informations utilisateur.
• Par défaut, l'installation d'ASP.NET n'active pas l'authentification par formulaires. Celle-ci doit être configurée de manière explicite pour chaque application pour être activée.
• Par défaut, IIS n'est pas installé.
• Par défaut, ASP.NET n'est pas installé lorsque .NET Framework est installé. Seuls les clients qui ont installé et activé manuellement ASP.NET peuvent être concernés par ce problème.
• L'attaquant devrait convaincre l'utilisateur de cliquer sur un lien afin de pouvoir exploiter cette vulnérabilité.

Une solution de contournement fait référence à une modification de paramètre ou de configuration qui ne corrige pas la vulnérabilité sous-jacente mais qui pourrait contribuer à bloquer certains vecteurs d'attaque connus jusqu'à ce que la mise à jour soit appliquée. Microsoft a testé les solutions de contournement suivantes et indique le cas échéant si une solution réduit certaines fonctionnalités :

• Désactiver l'authentification par formulaires dans web.config
  1. Ouvrez l'application ou le fichier web.config global après avoir créé une copie de sauvegarde.
  2. Définissez le mode d'authentification sur Windows, Passport ou Aucun.

     <system.web>

       <authentication mode="Windows | Passport | None" />

     </system.web>

     Les détails de chaque mode sont disponibles à l'adresse : http://msdn.microsoft.com/fr-fr/library/aa291347(v=vs.71).aspx.

     Comment annuler cette solution de contournement. 

     Restaurez votre fichier web.config grâce à votre copie de sauvegarde.

Quelle est la portée de cette vulnérabilité ? 
Il s'agit d'une vulnérabilité d'usurpation de contenu. Cette vulnérabilité pourrait permettre à un attaquant de rediriger un utilisateur vers un site Web du choix de l'attaquant à l'insu de l'utilisateur. L'attaquant pourrait alors exécuter une attaque d'hameçonnage pour obtenir des informations de l'utilisateur que celui-ci ne souhaitait pas révéler. Cette vulnérabilité ne permettrait pas à un attaquant d'exécuter du code ni d'élever directement ses droits d'utilisateur, mais elle pourrait être utilisée pour compromettre encore davantage les données utilisateur supposées rester privées.

Qu'est-ce que l'hameçonnage ? 
L'hameçonnage en ligne consiste à vous soutirer par la ruse des informations personnelles ou financières par le biais d'un message électronique ou d'un site Web. Une tentative d'hameçonnage en ligne courante commence par un message électronique qui ressemble à un avis officiel provenant d'une source fiable, telle qu'une banque, une société de carte de crédit ou un marchand en ligne de bonne réputation. Dans le message électronique, les destinataires sont dirigés vers un site Web frauduleux sur lequel ils doivent fournir des informations personnelles, telles qu'un numéro de compte ou un mot de passe. Ces informations sont alors généralement utilisées pour une usurpation d'identité.

Quelle est la cause de cette vulnérabilité ? 
Cette vulnérabilité est générée lorsque .NET Framework vérifie de façon incorrecte les URL de retour lors du processus d'authentification par formulaires.

Qu'est-ce que l'authentification par formulaires dans ASP.NET ? 
L'authentification par formulaires utilise un ticket d'authentification qui est créé lorsqu'un utilisateur ouvre une session sur un site et suit ensuite l'utilisateur sur le site. Le ticket d'authentification par formulaires est généralement contenu dans un cookie. Toutefois, ASP.NET version 2.0 prend en charge l'authentification par formulaires sans cookie, ce qui entraîne le passage du ticket dans une chaîne de requête. Pour plus d'informations, consultez l'article MSDN consacré à l'explication de l'authentification par formulaires dans ASP.NET 2.0 (en anglais).

Que pourrait faire un attaquant en exploitant cette vulnérabilité ? 
Un attaquant qui parviendrait à exploiter cette vulnérabilité pourrait rediriger un utilisateur vers un site Web du choix de l'attaquant à l'insu de l'utilisateur. Cette vulnérabilité ne permettrait pas à un attaquant d'exécuter du code ni d'élever directement ses droits d'utilisateur, mais elle pourrait être utilisée pour compromettre encore davantage les données utilisateur supposées rester privées.

Comment un attaquant pourrait-il exploiter cette vulnérabilité ? 
Un attaquant pourrait créer une URL spécialement conçue et convaincre un utilisateur de cliquer dessus. Lorsqu'un utilisateur ouvre une session sur un site Web prévu, l'attaquant redirige l'utilisateur vers un site Web contrôlé par l'attaquant. L'attaquant pourrait alors convaincre l'utilisateur de divulguer des informations qui devraient autrement rester privées. Cependant, l'attaquant n'aurait aucun moyen de forcer l'utilisateur à afficher le contenu contrôlé par l'attaquant. Un attaquant devrait plutôt convaincre des utilisateurs d'effectuer une action, en général de cliquer sur un lien contenu dans un message électronique ou dans un message instantané, qui dirigerait les utilisateurs vers le site Web de l'attaquant après avoir ouvert une session sur un site Web prévu.

Quels sont les systèmes les plus exposés à cette vulnérabilité ? 
Les systèmes directement connectés à Internet avec ASP.NET sont les plus exposés à cette vulnérabilité. De plus, les sites Web internes utilisant l'authentification par formulaires ASP.NET sont également exposés à cette vulnérabilité.

Que fait cette mise à jour ? 
Cette mise à jour corrige cette vulnérabilité en modifiant la façon dont .NET Framework vérifie les URL de retour lors de l'authentification par formulaires.

Lors de la parution de ce Bulletin de sécurité, cette vulnérabilité avait-elle été révélée publiquement ? 
Non. Microsoft a été informé de cette vulnérabilité par une divulgation de vulnérabilité coordonnée.

Lors de la parution de ce Bulletin de sécurité, Microsoft avait-il été informé d'une éventuelle exploitation de cette vulnérabilité ? 
Non. Lors de la première publication de ce Bulletin, Microsoft n'avait reçu aucune information faisant état d'une utilisation de cette vulnérabilité dans le but d'attaquer des clients.

Une atténuation fait référence à un paramètre, une configuration générale ou à des préférences existant dans un état par défaut qui pourraient diminuer l'impact de l'exploitation d'une vulnérabilité. Les facteurs atténuants suivants peuvent être utiles, selon votre situation :

• Un attaquant doit pouvoir enregistrer un compte sur l'application ASP.NET et connaître un nom d'utilisateur existant.
• Par défaut, l'installation d'ASP.NET n'active pas l'authentification par formulaires. Celle-ci doit être configurée de manière explicite pour chaque application pour être activée.
• Par défaut, IIS n'est pas installé.
• Par défaut, ASP.NET n'est pas installé lorsque .NET est installé. Seuls les clients qui ont installé et activé manuellement ASP.NET peuvent être concernés par ce problème.

Une solution de contournement fait référence à une modification de paramètre ou de configuration qui ne corrige pas la vulnérabilité sous-jacente mais qui pourrait contribuer à bloquer certains vecteurs d'attaque connus jusqu'à ce que la mise à jour soit appliquée. Microsoft a testé les solutions de contournement suivantes et indique le cas échéant si une solution réduit certaines fonctionnalités :

• Définir le paramètre ticketCompatibilityMode sur Framework40

  Cela s'applique uniquement aux sites qui exécutent ASP.NET 4 et versions ultérieures car le paramètre ticketCompatibilityMode a été introduit dans ASP.NET v4.0.

  1. Ouvrez l'application ou le fichier web.config global après avoir créé une copie de sauvegarde.
  2. Définissez le paramètre ticketCompatibilityMode sur Framework40. Notez que la valeur par défaut de ce paramètre est Framework20

     <system.web>
  <authentication mode="Forms">
    <forms ticketCompatibilityMode="Framework40" />
  </authentication>
</system.web>

  Comment annuler cette solution de contournement. 

  Restaurez votre fichier web.config grâce à votre copie de sauvegarde.

• Désactiver l'authentification par formulaires dans web.config
  1. Ouvrez l'application ou le fichier web.config global après avoir créé une copie de sauvegarde.
  2. Définissez le mode d'authentification sur Windows, Passport ou Aucun.

     <system.web>

       <authentication mode="Windows | Passport | None" />

     </system.web>

     Les détails de chaque mode sont disponibles à l'adresse : http://msdn.microsoft.com/fr-fr/library/aa291347(v=vs.71).aspx.

     Comment annuler cette solution de contournement. 

     Restaurez votre fichier web.config grâce à votre copie de sauvegarde.

Quelle est la portée de cette vulnérabilité ? 
Il s'agit d'une vulnérabilité d'élévation des privilèges où un attaquant distant non authentifié peut accéder à un autre compte sur l'application ASP.NET, lui permettant ainsi d'exécuter des commandes arbitraires sur le site dans le contexte de l'utilisateur ciblé.

Quelle est la cause de cette vulnérabilité ? 
Cette vulnérabilité est générée lorsqu'ASP.NET Framework authentifie de façon incorrecte des noms d'utilisateur spécialement conçus.

Que pourrait faire un attaquant en exploitant cette vulnérabilité ? 
Un attaquant qui parviendrait à exploiter cette vulnérabilité pourrait effectuer n'importe quelle action dans le contexte de l'utilisateur ciblé, y compris exécuter des commandes arbitraires sur le site.

Comment un attaquant pourrait-il exploiter cette vulnérabilité ? 
Pour pouvoir exploiter cette vulnérabilité, un attaquant non authentifié aurait d'abord besoin de connaître un nom de compte existant à imiter sur le site. L'attaquant pourrait alors concevoir une requête Web spéciale en utilisant un nom de compte précédemment enregistré pour pouvoir accéder à ce compte. L'attaquant pourrait alors effectuer n'importe quelle action dans le contexte de l'utilisateur ciblé, y compris exécuter des commandes arbitraires sur le site.

Quels sont les systèmes les plus exposés à cette vulnérabilité ? 
Les systèmes directement connectés à Internet avec ASP.NET sont les plus exposés à cette vulnérabilité. De plus, les sites Web internes utilisant l'authentification par formulaires ASP.NET sont également exposés à cette vulnérabilité.

Si mon site Web utilise une batterie de serveurs Web, aurai-je besoin de mettre à jour l'ensemble des ordinateurs de la batterie de serveurs Web ? 
Oui. Cette mise à jour modifie le format du ticket d'authentification par formulaires de manière à ce qu'il soit incompatible avec le format précédent. Cela signifie que les tickets générés à l'aide du nouveau comportement ne peuvent pas être lus par des ordinateurs qui utilisent l'ancien comportement, et inversement. Les administrateurs dont les applications utilisent l'authentification par formulaires doivent prendre des mesures spécifiques lors du déploiement de cette mise à jour de sécurité afin de veiller à ce que tous leurs serveurs passent simultanément au nouveau comportement.

Pour plus d'informations, consultez l'Article Microsoft TechNet 2659968 (en anglais).

Est-il possible de mettre à jour un à un les ordinateurs de ma batterie de serveurs Web au lieu de les mettre à jour tous en même temps ? 
Oui. S'il n'est pas possible de déployer MS11-100 simultanément sur tous les serveurs Web d'une batterie donnée, vous pouvez définir une option de compatibilité dans votre fichier web.config ou machine.config avant d'installer la mise à jour pour forcer l'ancien comportement une fois la mise à jour installée. L'option de compatibilité à utiliser est la suivante :

<appSettings>
  <add key="aspnet:UseLegacyFormsAuthenticationTicketCompatibility" value="true" />
</appSettings>

La définition de cette option permettra aux batteries de serveurs Web dont seulement certains ordinateurs sont mis à jour de continuer à fonctionner correctement. Toutefois, il est important de savoir que les ordinateurs sur lesquels l'option de configuration est définie se trouveront dans un état non sécurisé et qu'ils ne profiteront pas du correctif contenu dans cette mise à jour de sécurité. Après avoir déployé MS11-100 sur tous les ordinateurs d'une batterie, l'option de configuration doit être supprimée pour activer le nouveau comportement sécurisé.

Cette mise à jour respectera-t-elle le paramètre ticketCompatibilityMode d'authentification par formulaires de mon site ? 
Non. Étant donné que le correctif dans cette mise à jour de sécurité modifie le format des tickets d'authentification par formulaires, le paramètre de configuration ticketCompatibilityMode n'est plus pris en charge une fois MS11-100 installé.

Que fait cette mise à jour ? 
Cette mise à jour corrige cette vulnérabilité en modifiant la façon dont ASP.NET Framework authentifie les utilisateurs.

Lors de la parution de ce Bulletin de sécurité, cette vulnérabilité avait-elle été révélée publiquement ? 
Non. Microsoft a été informé de cette vulnérabilité par une divulgation de vulnérabilité coordonnée.

Lors de la parution de ce Bulletin de sécurité, Microsoft avait-il été informé d'une éventuelle exploitation de cette vulnérabilité ? 
Non. Lors de la première publication de ce Bulletin, Microsoft n'avait reçu aucune information faisant état d'une utilisation de cette vulnérabilité dans le but d'attaquer des clients.

Une atténuation fait référence à un paramètre, une configuration générale ou à des préférences existant dans un état par défaut qui pourraient diminuer l'impact de l'exploitation d'une vulnérabilité. Les facteurs atténuants suivants peuvent être utiles, selon votre situation :

• Par défaut, les réponses ASP.NET ne sont pas mises en cache par OutputCache. Le développeur du site doit activer la mise en cache de la sortie via la directive OutputCache sur une page.
• Tout attaquant qui parviendrait à exploiter cette vulnérabilité pourrait obtenir les mêmes droits que l'utilisateur cible. Les utilisateurs dont les comptes sont configurés avec des privilèges moins élevés sur le système subiraient moins d'impact que ceux qui possèdent des privilèges d'administrateur.
• Par défaut, IIS n'est installé sur aucune version du système d'exploitation affecté. Seuls les clients qui l'installent manuellement peuvent être concernés par ce problème.
• Par défaut, ASP.NET n'est pas installé lorsque .NET est installé. Seuls les clients qui ont installé et activé manuellement ASP.NET peuvent être concernés par ce problème.

Une solution de contournement fait référence à une modification de paramètre ou de configuration qui ne corrige pas la vulnérabilité sous-jacente mais qui pourrait contribuer à bloquer certains vecteurs d'attaque connus jusqu'à ce que la mise à jour soit appliquée. Microsoft a testé les solutions de contournement suivantes et indique le cas échéant si une solution réduit certaines fonctionnalités :

• Limiter les cookies d'authentification par formulaires aux canaux SSL

  Ouvrez l'application ou le fichier web.config global après avoir créé une copie de sauvegarde.

  Définissez requireSSL="true" sur l'élément <forms>, comme indiqué dans le code suivant.

  <forms loginUrl="Secure\Login.aspx"
    requireSSL="true" />

  Comment annuler cette solution de contournement. 

  Restaurez votre fichier web.config grâce à votre copie de sauvegarde.

• Désactiver l'expiration glissante pour les cookies d'authentification par formulaires
  1. Ouvrez l'application ou le fichier web.config global après avoir créé une copie de sauvegarde.
  2. Définissez slidingExpiration="false" sur l'élément <forms>, comme indiqué dans le code suivant.

     <forms slidingExpiration="false"/>

  Impact de cette solution de contournement. Les utilisateurs sont obligés à ouvrir à nouveau une session après l'expiration de leurs tickets.

  Comment annuler cette solution de contournement. 

  Restaurez votre fichier web.config grâce à votre copie de sauvegarde.

• Désactiver OutputCache
  1. Sauvegardez votre dossier d'application Web.
  2. Supprimez toutes les directives <%@ OutputCache %> de vos pages Web.
  3. Si votre site Web est une application MVC, supprimez également tous les attributs OutputCache des actions de votre contrôleur.

  Impact de cette solution de contournement. Les utilisateurs sont obligés à ouvrir à nouveau une session après l'expiration de leurs tickets.

  Comment annuler cette solution de contournement. 

  Restaurez votre dossier d'application Web.

Quelle est la portée de cette vulnérabilité ? 
Il s'agit d'une vulnérabilité d'élévation des privilèges où un attaquant distant non authentifié accède à un autre compte sur l'application .NET.

Quelle est la cause de cette vulnérabilité ? 
Cette vulnérabilité est générée lorsque .NET Framework traite de façon incorrecte le contenu mis en cache lorsque l'authentification par formulaires est utilisée avec une expiration glissante.

Que pourrait faire un attaquant en exploitant cette vulnérabilité ? 
Un attaquant qui parviendrait à exploiter cette vulnérabilité pourrait effectuer n'importe quelle action que l'utilisateur pourrait effectuer sur le site dans le contexte de l'utilisateur ciblé, y compris exécuter des commandes arbitraires.

Comment un attaquant pourrait-il exploiter cette vulnérabilité ? 
Dans le cas d'une attaque par courrier électronique, un attaquant pourrait exploiter cette vulnérabilité en envoyant un lien spécialement conçu à un utilisateur et en persuadant celui-ci de cliquer dessus. Un attaquant n'aurait aucun moyen de forcer un utilisateur à visiter le site Web. Il devrait l'inciter à prendre des mesures, généralement en cliquant sur un lien dans un message électronique ou dans un message instantané.

Qu'est-ce que l'authentification par formulaires dans ASP.NET ? 
L'authentification par formulaires utilise un ticket d'authentification qui est créé lorsqu'un utilisateur ouvre une session sur un site et suit ensuite l'utilisateur sur le site. Le ticket d'authentification par formulaires est généralement contenu dans un cookie. Toutefois, ASP.NET version 2.0 prend en charge l'authentification par formulaires sans cookie, ce qui entraîne le passage du ticket dans une chaîne de requête. Pour plus d'informations, consultez l'article MSDN consacré à l'explication de l'authentification par formulaires dans ASP.NET 2.0 (en anglais).

Quels sont les systèmes les plus exposés à cette vulnérabilité ? 
Les systèmes directement connectés à Internet avec IIS et ASP.NET sont les plus exposés à cette vulnérabilité. De plus, les sites Web internes utilisant l'authentification par formulaires ASP.NET sont également exposés à cette vulnérabilité.

Que fait cette mise à jour ? 
Cette mise à jour corrige la façon dont ASP.NET traite le contenu mis en cache.

Lors de la parution de ce Bulletin de sécurité, cette vulnérabilité avait-elle été révélée publiquement ? 
Non. Microsoft a été informé de cette vulnérabilité par une divulgation de vulnérabilité coordonnée.

Lors de la parution de ce Bulletin de sécurité, Microsoft avait-il été informé d'une éventuelle exploitation de cette vulnérabilité ? 
Non. Lors de la première publication de ce Bulletin, Microsoft n'avait reçu aucune information faisant état d'une utilisation de cette vulnérabilité dans le but d'attaquer des clients.

Tableau de référence

Le tableau suivant contient les informations de mise à jour de sécurité concernant ce logiciel. Vous pouvez rechercher des informations supplémentaires dans la sous-section « Informations de déploiement » de cette section.

Remarque : La mise à jour pour les versions en cours de support de Windows XP Professionnel Édition x64 s'applique également aux versions en cours de support de Windows Server 2003 Édition x64.

Tableau de référence

Le tableau suivant contient les informations de mise à jour de sécurité concernant ce logiciel. Vous pouvez rechercher des informations supplémentaires dans la sous-section « Informations de déploiement » de cette section.

Remarque : La mise à jour pour les versions en cours de support de Windows Server 2003 Édition x64 s'applique également aux versions en cours de support de Windows XP Professionnel Édition x64.

Tableau de référence

Le tableau suivant contient les informations de mise à jour de sécurité concernant ce logiciel. Vous pouvez rechercher des informations supplémentaires dans la sous-section « Informations de déploiement » de cette section.

Tableau de référence

Le tableau suivant contient les informations de mise à jour de sécurité concernant ce logiciel. Vous pouvez rechercher des informations supplémentaires dans la sous-section « Informations de déploiement » de cette section.

Tableau de référence

Le tableau suivant contient les informations de mise à jour de sécurité concernant ce logiciel. Vous pouvez rechercher des informations supplémentaires dans la sous-section « Informations de déploiement » de cette section.

Tableau de référence

Le tableau suivant contient les informations de mise à jour de sécurité concernant ce logiciel. Vous pouvez rechercher des informations supplémentaires dans la sous-section « Informations de déploiement » de cette section.