Práticas recomendadas de segurança no WCF
As seções a seguir listam as práticas recomendadas a serem consideradas ao criar aplicativos seguros usando o Windows Communication Foundation (WCF). Para obter mais informações sobre segurança, consulte Considerações de segurança, Considerações de segurança para dados e Considerações de segurança com metadados.
Identificar serviços que executam autenticação do Windows com SPNs
Os serviços podem ser identificados com UPNs (nomes principais de usuário) ou SPNs (nomes principais de serviço). Os serviços executados em contas de máquina, como o serviço de rede, têm uma identidade SPN correspondente à máquina que estão executando. Os serviços executados em contas de usuário têm uma identidade UPN correspondente ao usuário como estão sendo executados, embora a setspn ferramenta possa ser usada para atribuir um SPN à conta de usuário. Configurar um serviço para que ele possa ser identificado via SPN e configurar os clientes que se conectam ao serviço para usar esse SPN pode dificultar certos ataques. Esta orientação se aplica a associações que usam negociação Kerberos ou SSPI. Os clientes ainda devem especificar um SPN no caso em que o SSPI retorne ao NTLM.
Verificar identidades de serviço no WSDL
O WS-SecurityPolicy permite que os serviços publiquem informações sobre suas próprias identidades em metadados. Quando recuperadas via svcutil ou outros métodos, como WsdlImporter, essas informações de identidade são convertidas para as propriedades de identidade dos endereços de ponto de extremidade do serviço WCF. Os clientes que não verificam se essas identidades de serviço estão corretas e válidas efetivamente ignoram a autenticação do serviço. Um serviço mal-intencionado pode explorar esses clientes para executar o encaminhamento de credenciais e outros ataques "man in the middle" alterando a identidade reivindicada em seu WSDL.
Usar certificados X509 em vez de NTLM
O WCF oferece dois mecanismos para autenticação ponto a ponto: certificados X509 (usados por canal de mesmo nível) e autenticação do Windows, onde uma negociação SSPI faz downgrade de Kerberos para NTLM. A autenticação baseada em certificado usando tamanhos de chave de 1024 bits ou mais é preferível ao NTLM por vários motivos:
a disponibilidade de autenticação mútua,
a utilização de algoritmos criptográficos mais fortes, e
a maior dificuldade de utilizar credenciais X509 encaminhadas.
Sempre reverter após a representação
Ao usar APIs que permitem a representação de um cliente, certifique-se de reverter para a identidade original. Por exemplo, ao usar o WindowsIdentity e WindowsImpersonationContext, use a instrução C# using ou a instrução Visual Basic Using , conforme mostrado no código a seguir. A WindowsImpersonationContext classe implementa a IDisposable interface e, portanto, o Common Language Runtime (CLR) reverte automaticamente para a identidade original assim que o código sai do using bloco.
WindowsIdentity identity = ServiceSecurityContext.Current.WindowsIdentity;
using (identity.Impersonate())
{
// Run code under the caller's identity.
}
Dim identity = ServiceSecurityContext.Current.WindowsIdentity
Using identity.Impersonate()
' Run code under the caller's identity.
End Using
Personifique apenas quando necessário
Usando o Impersonate método da classe, é possível usar a WindowsIdentity representação em um escopo muito controlado. Isso contrasta com o Impersonation uso da propriedade do OperationBehaviorAttribute, que permite a representação para o escopo de toda a operação. Sempre que possível, controle o escopo da representação usando o método mais preciso Impersonate .
Obter metadados de fontes confiáveis
Certifique-se de que confia na origem dos seus metadados e certifique-se de que ninguém os adulterou. Os metadados recuperados usando o protocolo HTTP são enviados em texto não criptografado e podem ser adulterados. Se o serviço usar as HttpsGetEnabled propriedades e HttpsGetUrl , use a URL fornecida pelo criador do serviço para baixar os dados usando o protocolo HTTPS.
Publicar metadados usando segurança
Para evitar a adulteração dos metadados publicados de um serviço, proteja o ponto de extremidade de troca de metadados com segurança em nível de transporte ou mensagem. Para obter mais informações, consulte Publicando pontos de extremidade de metadados e Como publicar metadados para um serviço usando código.
Garantir o uso do emissor local
Se um endereço de emissor e uma ligação forem especificados para uma determinada ligação, o emissor local não será usado para pontos de extremidade que usam essa ligação. Os clientes que esperam utilizar sempre o emitente local devem assegurar-se de que não utilizam essa ligação ou que modificam a ligação de modo a que o endereço do emitente seja nulo.
Cotas de tamanho de token SAML
Quando os tokens SAML (Security Assertions Markup Language) são serializados em mensagens, seja quando são emitidos por um STS (Serviço de Token de Segurança) ou quando os clientes os apresentam aos serviços como parte da autenticação, a cota de tamanho máximo de mensagem deve ser suficientemente grande para acomodar o token SAML e as outras partes da mensagem. Em casos normais, as cotas de tamanho de mensagem padrão são suficientes. No entanto, nos casos em que um token SAML é grande porque contém centenas de declarações, as cotas devem ser aumentadas para acomodar o token serializado. Para obter mais informações sobre cotas, consulte Considerações de segurança para dados.
Defina SecurityBindingElement.IncludeTimestamp como True em ligações personalizadas
Ao criar uma associação personalizada, você deve definir IncludeTimestamp como true. Caso contrário, se IncludeTimestamp estiver definido como false, e o cliente estiver usando um token baseado em chave assimétrica, como um certificado X509, a mensagem não será assinada.