Requêtes Web et WebSockets sécurisés

​

Communication avec les services XBOX

Utilisez l’API des services XBOX (XSAPI) pour les appels aux services XBOX. Elle repose sur les API HTTP et WebSocket de la plateforme, suit toutes les pratiques de sécurité recommandées et est offerte sur plusieurs plateformes. Consultez Prise en main des API des services XBOX.

​

Communication avec les services PlayFab

Utilisez la bibliothèque GDK PlayFab XplatCPP. Elle suit les pratiques de sécurité recommandées, y compris l’authentification, et repose sur les API HTTP et WebSocket de la plateforme. Consultez la bibliothèque GDK PlayFab Azure privée et la documentation du SDK XplatCPP.

​

Communication générale avec les services Web

Sur le GDK, utilisez XCurl, libHttpClient ou WinHTTP. Microsoft les teste et les maintient activement.

• XCurl impose automatiquement la validation complète des certificats SSL.
• libHttpClient convient le mieux à la communication WebSocket.
• Utilisez toujours HTTPS / WSS. Limitez-vous à TLS 1.2 ou 1.3 seulement.

Consultez la Vue d’ensemble des requêtes Web.

​

Authentification des services Web

Authentifiez les services Web à l’aide de certificats SSL publics dont la racine est une autorité de certification reconnue par la plateforme. Consultez Participants au programme de racines approuvées de Microsoft. WinHTTP et XCurl valident automatiquement les certificats. Les certificats autosignés ou émis par une autorité de certification non prise en charge provoquent des erreurs d’authentification. Pendant le développement, vous pouvez contourner ou réduire ces vérifications — ne livrez jamais ces modifications dans les builds de publication.

​

Pratiques exemplaires pour la pile HTTP

Si votre titre utilise directement WinHTTP ou une autre pile HTTP au lieu de xCurl, configurez explicitement la sécurité — les paramètres par défaut de xCurl ne s’appliquent pas automatiquement ailleurs.

​

Validation des certificats et approbation

• Validez la chaîne de certificats complète.
• Validez le nom d’hôte du serveur, et pas seulement l’émetteur.
• Déterminez si la pile utilise le modèle d’approbation de la plateforme ou un ensemble d’approbation géré séparément.

Le chargement d’un certificat racine de débogage de type Fiddler est une action explicite dans votre pile.

​

Configuration du proxy

• Découvrez la configuration du proxy système lorsque c’est approprié.
• Transmettez explicitement les paramètres de proxy à la bibliothèque HTTP.
• Testez le trafic direct et le trafic passant par un proxy (particulièrement pour le débogage local).

Consultez Débogage des piles HTTP personnalisées pour la gestion du proxy XBOX avec les piles autres que Schannel.

​

Paramètres sécurisés par défaut à examiner

• Délais d’expiration de connexion et de requête
• Gestion des redirections
• Limites de taille des requêtes et des réponses
• Comportement selon la version HTTP (y compris les hypothèses relatives à HTTP/2)
• Masquage des en-têtes, jetons et URL dans la journalisation et la télémétrie

​

Liste de vérification recommandée

• Le trafic de production utilise HTTPS ou WSS.
• La validation de la chaîne de certificats et du nom d’hôte est activée dans les builds de publication.
• Le modèle d’approbation est déterminé et documenté.
• La découverte du proxy ou sa configuration explicite est prise en charge pour les flux de travail de débogage.
• Les échecs de certificat, les échecs de proxy et le comportement des délais d’expiration sont délibérément testés (pas seulement le scénario idéal).

​

Authentification du client

Authentifiez les clients GDK à l’aide du jeton d’authentification XSTS. Les services XBOX créent le jeton et fournissent les revendications d’utilisateur, de client et de privilèges. Les clients peuvent utiliser les jetons XSTS pour les appels aux services du titre lorsque ceux-ci peuvent être validés de façon sécurisée. Conseils :

• Configurez les revendications d’authentification XSTS dans Partner Center dans le cadre de la configuration du titre ou du service.
• N’envoyez pas les renseignements d’utilisateur, de client ou de privilèges directement depuis le client (dans l’URL ou le corps). Validez-les toujours au moyen des revendications XSTS.
• Les jetons personnalisés du titre ou de l’éditeur sont permis, mais doivent reposer sur un flux d’authentification XSTS initial. Suivez le format JWT chiffré et l’expiration utilisés par XSTS.

Consultez Authentification des services XBOX et l’exemple GameService pour la validation XSTS.

​

Configuration des algorithmes pour les services Web

Limitez TLS aux options robustes seulement :

• AES256 ou plus robuste
• Chiffrements CBC ou GCM
• SHA256 ou plus robuste

AES256 bénéficie de l’accélération matérielle sur les processeurs modernes. Les autres options comportent des vulnérabilités connues. WinHTTP et XCurl imposent SHA256 (ou supérieur) pour tous les certificats SSL, y compris les certificats autosignés. Consultez Windows Enforcement of SHA1 Certificates.

​

Génération de certificats SSL

Les certificats racines doivent être l’un ou l’autre des suivants :

• Une autorité de certification chaînée à un participant du Programme de racines approuvées de Microsoft. Aucune configuration par titre n’est requise.
• Une autorité de certification Microsoft (y compris les certificats Azure utilisés dans les machines virtuelles et services Azure).

Des options de certificats gratuites et payantes existent — choisissez celle qui vous convient.

​

Documentation d’API connexe

• Référence de l’API XCurl — options TLS, application du HTTPS seulement, points d’ancrage pour l’épinglage de certificats
• Référence libHttpClient — transport HTTPS/WebSocket sous XSAPI
  
  
  - Référence REST XSAPI — requêtes Web authentifiées par XSTS
• Référence XUser — XUserGetTokenAndSignatureAsync pour les requêtes Web authentifiées

​

Voir aussi

• Vue d’ensemble des requêtes Web
• XCurl (concepts GDK)
• WinHTTP (concepts GDK)
• Vue d’ensemble de la sécurité des communications