Solicitações da Web e WebSockets seguros

​

Comunicação com os XBOX services

Use a XBOX Services API (XSAPI) para chamadas aos XBOX services. Ela é baseada nas APIs HTTP e WebSocket da plataforma, segue todas as práticas de segurança recomendadas e está disponível em várias plataformas. Consulte Introdução às XBOX Services APIs.

​

Comunicação com os serviços do PlayFab

Use a biblioteca GDK PlayFab XplatCPP. Ela segue as práticas de segurança recomendadas, incluindo autenticação, e é baseada nas APIs HTTP e WebSocket da plataforma. Consulte a biblioteca GDK privada do Azure PlayFab e a documentação do SDK XplatCPP.

​

Comunicação geral com serviços Web

No GDK, use XCurl, libHttpClient ou WinHTTP. A Microsoft testa e mantém essas bibliotecas ativamente.

• O XCurl impõe automaticamente a validação completa de certificados SSL.
• O libHttpClient é mais adequado para comunicação via WebSocket.
• Sempre use HTTPS / WSS. Restrinja apenas a TLS 1.2 ou 1.3.

Consulte a Visão geral das solicitações da Web.

​

Autenticação de serviços Web

Autentique os serviços Web usando certificados SSL públicos com raiz em uma AC reconhecida pela plataforma. Consulte Microsoft Trusted Root Participants. O WinHTTP / XCurl validam os certificados automaticamente. Certificados autoassinados ou de ACs sem suporte causam erros de autenticação. Durante o desenvolvimento, você pode substituir ou reduzir essas verificações; nunca inclua essas alterações em builds de lançamento.

​

Práticas recomendadas para a pilha HTTP

Se o seu título usar o WinHTTP ou outra pilha HTTP diretamente em vez do xCurl, configure a segurança explicitamente: os padrões do xCurl não são automáticos em outros lugares.

​

Validação e confiança de certificados

• Valide a cadeia completa de certificados.
• Valide o nome do host do servidor, não apenas o emissor.
• Decida se a pilha usa o modelo de confiança da plataforma ou um pacote de confiança gerenciado separadamente.

Carregar um certificado raiz de depuração no estilo do Fiddler é uma ação explícita na sua pilha.

​

Configuração de proxy

• Descubra a configuração de proxy do sistema quando apropriado.
• Passe as configurações de proxy para a biblioteca HTTP explicitamente.
• Teste o tráfego direto e via proxy (especialmente para depuração local).

Consulte Depuração de pilhas HTTP personalizadas para o tratamento de proxy do XBOX em pilhas que não usam Schannel.

​

Padrões seguros a revisar

• Tempos limite de conexão e de solicitação
• Tratamento de redirecionamentos
• Limites de tamanho de solicitação / resposta
• Comportamento da versão HTTP (incluindo suposições sobre HTTP/2)
• Ocultação de cabeçalhos, tokens e URLs no registro em log e na telemetria

​

Lista de verificação recomendada

• O tráfego de produção é HTTPS ou WSS.
• A validação da cadeia de certificados e do nome do host está ativada nos builds de lançamento.
• O modelo de confiança está decidido e documentado.
• A descoberta de proxy / configuração explícita tem suporte para fluxos de trabalho de depuração.
• Falhas de certificado, falhas de proxy e o comportamento de tempo limite são testados deliberadamente (não apenas o caminho feliz).

​

Autenticação do cliente

Autentique os clientes GDK usando o token de autenticação XSTS. Os XBOX services criam o token e fornecem declarações de usuário, cliente e privilégios. Os clientes podem usar tokens XSTS para chamadas aos serviços do título quando eles puderem ser validados com segurança. Diretrizes:

• Configure as declarações de autenticação XSTS no Partner Center como parte da configuração do título/serviço.
• Não envie informações de usuário/cliente/privilégios diretamente do cliente (URL ou corpo). Sempre valide por meio das declarações XSTS.
• Tokens personalizados do título/editor são permitidos, mas devem se basear em um fluxo inicial de autenticação XSTS. Siga o formato JWT criptografado e a expiração usados pelo XSTS.

Consulte Autenticação dos XBOX services e o exemplo GameService para a validação XSTS.

​

Configuração de algoritmos para serviços Web

Limite o TLS apenas a opções fortes:

• AES256 ou mais forte
• Cifras CBC ou GCM
• SHA256 ou mais forte

O AES256 tem aceleração de hardware em CPUs modernas. Outras opções têm vulnerabilidades conhecidas. O WinHTTP / XCurl impõem SHA256 (ou superior) em todos os certificados SSL, incluindo os autoassinados. Consulte Windows Enforcement of SHA1 Certificates.

​

Geração de certificados SSL

Os certificados raiz devem ser:

• Uma AC encadeada a um participante do Microsoft Trusted Root Program. Nenhuma configuração por título é necessária.
• Uma AC da Microsoft (incluindo certificados do Azure usados em VMs e serviços do Azure).

Existem opções de certificados gratuitas e pagas; escolha a que melhor se adequar.

​

Documentação de API relacionada

• Referência da API XCurl: opções de TLS, imposição somente de HTTPS, ganchos de fixação de certificados
• Referência do libHttpClient: transporte HTTPS/WebSocket sob o XSAPI
• Referência REST do XSAPI: solicitações da Web autenticadas por XSTS
• Referência do XUser: XUserGetTokenAndSignatureAsync para solicitações da Web autenticadas

​

Confira também

• Visão geral das solicitações da Web
• XCurl (conceitual do GDK)
• WinHTTP (conceitual do GDK)
• Visão geral da segurança de comunicação