Divulgação de Informações
A divulgação de informações permite que um invasor obtenha informações valiosas sobre um sistema. Portanto, sempre considere quais informações você está revelando e se elas podem ser usadas por um usuário mal-intencionado. A lista a seguir lista possíveis ataques de divulgação de informações e fornece mitigações para cada um.
Segurança de mensagens e HTTP
Se você estiver usando a segurança no nível da mensagem em uma camada de transporte HTTP, lembre-se de que a segurança no nível da mensagem não protege cabeçalhos HTTP. A única maneira de proteger cabeçalhos HTTP é usar transporte HTTPS em vez de HTTP. O transporte HTTPS faz com que toda a mensagem, incluindo os cabeçalhos HTTP, seja criptografada usando o protocolo SSL (Secure Sockets Layer).
Informação sobre políticas
Manter a política segura é importante, especialmente em cenários de federação em que requisitos confidenciais de token emitido ou informações do emissor de token são expostas na política. Nesses casos, a recomendação é proteger o ponto de extremidade da política do serviço federado para impedir que invasores obtenham informações sobre o serviço, como o tipo de declarações a serem colocadas no token emitido ou redirecionem clientes para emissores de token mal-intencionados. Por exemplo, um invasor pode descobrir pares de nome de usuário/senha reconfigurando a cadeia de confiança federada para terminar em um emissor que executou um ataque man-in-the-middle. Também é recomendável que os clientes federados que obtêm suas associações por meio da recuperação de políticas verifiquem se confiam nos emissores na cadeia de confiança federada obtida. Para obter mais informações sobre cenários de federação, consulte Federação.
Despejos de memória podem revelar informações de declaração
Quando um aplicativo falha, os arquivos de log, como os produzidos pelo Dr. Watson, podem conter as informações da declaração. Esta informação não deve ser exportada para outras entidades, como equipas de apoio; caso contrário, as informações de declaração que contêm dados privados também serão exportadas. Você pode atenuar isso não enviando os arquivos de log para entidades desconhecidas.
Endereços de ponto final
Um endereço de ponto de extremidade contém as informações necessárias para se comunicar com um ponto de extremidade. A segurança SOAP deve incluir o endereço completo nas mensagens de negociação de segurança trocadas para negociar uma chave simétrica entre um cliente e um servidor. Como a negociação de segurança é um processo de bootstrap, os cabeçalhos de endereço não podem ser criptografados durante esse processo. Por conseguinte, o endereço não deve conter quaisquer dados confidenciais; caso contrário, leva a ataques de divulgação de informações.
Certificados transferidos sem criptografia
Quando você usa um certificado X.509 para autenticar um cliente, o certificado é transferido de forma clara, dentro do cabeçalho SOAP. Esteja ciente disso como uma potencial divulgação de informações de identificação pessoal (PII). Isso não é um problema para TransportWithMessageCredential o modo, onde toda a mensagem é criptografada com segurança de nível de transporte.
Referências de Serviço
Uma referência de serviço é uma referência a outro serviço. Por exemplo, um serviço pode passar uma referência de serviço para um cliente durante uma operação. A referência de serviço também é usada com um verificador de identidade de confiança, um componente interno que garante a identidade da entidade de destino antes de divulgar informações como dados de aplicativo ou credenciais para o destino. Se a identidade de confiança remota não puder ser verificada ou estiver incorreta, o remetente deve garantir que nenhum dado foi divulgado que possa comprometer a si mesmo, o aplicativo ou o usuário.
As atenuações incluem o seguinte:
As referências de serviço são consideradas confiáveis. Tenha cuidado ao transferir instâncias de referência de serviço para garantir que elas não tenham sido adulteradas.
Alguns aplicativos podem apresentar uma experiência de usuário que permite o estabelecimento interativo de confiança com base em dados na referência de serviço e dados de confiança comprovados pelo host remoto. O WCF fornece pontos de extensibilidade para tal recurso, mas o usuário deve implementá-los.
NTLM
Por padrão, no ambiente de domínio do Windows, a autenticação do Windows usa o protocolo Kerberos para autenticar e autorizar usuários. Se o protocolo Kerberos não puder ser usado por algum motivo, o NT LAN Manager (NTLM) será usado como um fallback. Você pode desabilitar esse comportamento definindo a AllowNtlm propriedade como false. Os problemas a ter em conta ao permitir o NTLM incluem:
NTLM expõe o nome de usuário do cliente. Se o nome de usuário precisar ser mantido confidencial, defina a
AllowNTLMpropriedade na associação comofalse.NTLM não fornece autenticação de servidor. Portanto, o cliente não pode garantir que ele está se comunicando com o serviço certo quando você usa NTLM como um protocolo de autenticação.
Especificar credenciais de cliente ou identidade inválida força o uso de NTLM
Ao criar um cliente, especificar credenciais de cliente sem um nome de domínio ou especificar uma identidade de servidor inválida, faz com que o NTLM seja usado em vez do protocolo Kerberos (se a AllowNtlm propriedade estiver definida como true). Como o NTLM não faz autenticação de servidor, as informações podem ser divulgadas.
Por exemplo, é possível especificar credenciais de cliente Windows sem um nome de domínio, conforme mostrado no seguinte código do Visual C#.
MyChannelFactory.Credentials.Windows.ClientCredential = new System.Net.NetworkCredential("username", "password");
O código não especifica um nome de domínio e, portanto, NTLM será usado.
Se o domínio for especificado, mas um nome de entidade de serviço inválido for especificado usando o recurso de identidade do ponto de extremidade, o NTLM será usado. Para obter mais informações sobre como a identidade do ponto de extremidade é especificada, consulte Identidade e autenticação do serviço.