Partager via

Considérations relatives à la sécurité de WinHTTP

  • Article

Les considérations de sécurité suivantes s’appliquent aux applications qui utilisent WinHTTP :

  • Les certificats serveur ne sont vérifiés qu’une seule fois par session. Après qu’un certificat a été vérifié, il reste valide pour la durée de la session en cours. Tant que l’empreinte digitale du certificat correspond, ce qui indique que le certificat n’a pas changé, le certificat continue d’être revalidé. En conséquence, tout changement dans les critères de validation, via le protocole, la vérification de révocation ou les indicateurs d’ignorance des erreurs de certificat, ne prend pas effet une fois le certificat vérifié. Pour forcer un tel changement à prendre effet immédiatement, la session en cours doit être terminée et une nouvelle commencée. De même, l’expiration d’un certificat au cours d’une session ne peut être détectée que si l’application elle-même vérifie périodiquement le serveur de certificats pour récupérer les données d’expiration.
  • L’auto-proxy implique le téléchargement et l’exécution de scripts. Le support de la découverte automatique de proxy implique la détection via DHCP ou DNS, le téléchargement et l’exécution de scripts proxy tels que des scripts Java. Pour atteindre un niveau de sécurité plus élevé, une application doit éviter de passer l’indicateur WINHTTP_AUTOPROXY_RUN_INPROCESS, afin que la découverte automatique du proxy soit initiée hors processus. Même alors, WinHTTP essaie par défaut d’exécuter un script auto-proxy en processus si le script échoue à s’exécuter correctement hors processus. Si vous pensez que ce comportement de secours pose un risque inacceptable, désactivez le comportement de secours avec l’indicateur WINHTTP_AUTOPROXY_RUN_OUTPROCESS_ONLY.
  • Les fonctions WINHTTP_STATUS_CALLBACK doivent être retournées rapidement. Lorsque vous écrivez l’une de ces fonctions de rappel, veillez à ce qu’elle ne bloque pas. Par exemple, ni le rappel ni aucune fonction qu’il appelle ne doivent afficher une boîte de dialogue utilisateur ou attendre un événement. Si une fonction WINHTTP_STATUS_CALLBACK bloque, cela affecte la planification interne de WinHTTP et cause le refus de service des autres demandes au sein du même processus.
  • Les fonctions WINHTTP_STATUS_CALLBACK doivent être ré-entrantes. Lors de l’écriture d’un rappel, évitez les variables statiques ou autres constructions qui ne sont pas sûres en réentrance, et évitez d’appeler d’autres fonctions qui ne sont pas ré-entrantes.
  • Si une opération asynchrone est possible, passez des valeurs NULL pour les paramètres OUT. Si vous avez activé l’opération asynchrone en enregistrant une fonction de rappel, passez toujours des valeurs NULL pour ces paramètres OUT tels que lpdwDataAvailable pour WinHttpQueryDataAvailable, lpdwBytesRead pour WinHttpReadData, ou lpdwBytesWritten pour WinHttpWriteData. Dans certaines circonstances, le thread appelant est terminé avant la fin de l’opération, et si les paramètres OUT ne sont pas NULL, la fonction peut finir par écrire dans une mémoire qui a déjà été libérée.
  • L’authentification Passport n’est pas infaillible. Tout schéma d’authentification basé sur des cookies est vulnérable aux attaques. La version 1.4 de Passport est basée sur des cookies et est donc sujette aux vulnérabilités associées à tout schéma d’authentification par cookie ou formulaire. Le support de Passport est désactivé par défaut dans WinHTTP ; il peut être activé en utilisant WinHttpSetOption.
  • L’authentification de base ne doit être utilisée que sur une connexion sécurisée. L’authentification de base, qui envoie le nom d’utilisateur et le mot de passe en clair (voir RFC 2617), ne doit être utilisée que sur des connexions SSL ou TLS chiffrées.
  • Définir la politique de connexion automatique sur « faible » peut poser un risque. Lorsque la politique de connexion automatique est définie sur faible, les informations d’identification de connexion d’un utilisateur peuvent être utilisées pour s’authentifier contre n’importe quel site. Cependant, il n’est pas bon de s’authentifier contre des sites en lesquels vous n’avez pas confiance.
  • Les connexions SSL 2.0 ne sont pas utilisées sauf si elles sont explicitement activées. Les protocoles de sécurité TLS 1.0 et SSL 3.0 sont considérés comme plus sûrs que SSL 2.0. Par défaut, WinHTTP demande TLS 1.0 ou SSL 3.0 lors de la négociation d’une connexion SSL, pas SSL 2.0. Le support de SSL 2.0 dans WinHTTP ne peut être activé qu’en appelant WinHttpSetOption.
  • La vérification de la révocation des certificats doit être demandée explicitement. Par défaut, lors de l’authentification des certificats, WinHTTP ne vérifie pas si le certificat du serveur a été révoqué. La vérification de la révocation des certificats peut être activée en utilisant WinHttpSetOption.
  • Les applications doivent s’assurer qu’une session correspond à une seule identité. Une session WinHTTP doit correspondre à une et une seule identité ; c’est-à-dire qu’une session WinHTTP est utilisée pour gérer l’activité Internet d’un seul utilisateur authentifié ou d’un groupe d’utilisateurs anonymes. Cependant, comme WinHTTP n’applique pas automatiquement cette correspondance, votre application doit prendre des mesures pour s’assurer qu’une seule identité est impliquée.
  • Les opérations sur un handle de demande WinHTTP doivent être synchronisées. Par exemple, une application doit éviter de fermer un handle de demande sur un thread pendant qu’un autre thread envoie ou reçoit une demande. Pour terminer une demande asynchrone, fermez le handle de demande pendant une notification de rappel. Pour terminer une demande synchrone, fermez le handle lorsque l’appel WinHTTP précédent revient.
  • Les fichiers de trace contiennent des informations sensibles. Les fichiers de trace sont protégés à l’aide de listes de contrôle d’accès (ACL) de sorte qu’ils ne peuvent normalement être accessibles que par l’administrateur local ou par le compte utilisateur qui les a créés.
  • Évitez de passer des données sensibles via WinHttpSetOption. Ne fournissez pas un nom d’utilisateur, un mot de passe ou d’autres informations d’identification à WinHttpSetOption car vous n’avez aucun contrôle sur le schéma d’authentification utilisé, et les données sensibles pourraient être envoyées en clair de manière inattendue. Utilisez WinHttpQueryAuthSchemes et WinHttpSetCredentials au lieu de WinHttpSetOption pour définir les informations d’identification.
  • La redirection automatique peut poser un risque de sécurité. Par défaut, la redirection (un message 302) est suivie automatiquement même pour un POST. Pour éviter la possibilité de redirections fallacieuses, les applications doivent désactiver la redirection automatique ou surveiller la redirection dans les rappels lors de la publication d’informations sensibles.
  • Les en-têtes définis par l’utilisateur sont transférés sans changement lors des redirections. Les en-têtes définis par l’utilisateur, tels que les cookies ajoutés avec WinHTTPAddRequestHeaders, sont transférés sans modification lors des redirections, tandis que les en-têtes générés par WinHTTP sont automatiquement mis à jour. Si le transfert d’un en-tête défini par l’utilisateur lors des redirections pose un risque de sécurité, utilisez le rappel WINHTTP_STATUS_CALLBACK avec l’achèvement WINHTTP_CALLBACK_STATUS_REDIRECT pour modifier l’en-tête en question chaque fois qu’une redirection se produit.
  • WinHTTP n’est pas ré-entrant en mode synchrone. Parce que WinHTTP n’est pas réentrant en mode synchrone, ne planifiez pas d’appels de procédure asynchrones (APC) qui peuvent appeler WinHTTP sur un thread d’application qui s’exécute dans une fonction WinHTTP. En mode synchrone, WinHTTP effectue une « attente alertable », et si le thread en attente est préempté pour exécuter un APC puis ré-entre à nouveau dans WinHTTP, l’état interne de WinHTTP peut être corrompu.