Negação de Serviço
A negação de serviço ocorre quando um sistema é sobrecarregado de tal forma que as mensagens não podem ser processadas ou são processadas de modo extremamente lento.
Consumo de memória excessiva
Um problema pode ocorrer ao ler um documento XML com um grande número de nomes locais exclusivos, namespaces ou prefixos. Se você estiver usando uma classe que deriva de XmlReader e chamar a propriedade LocalName, Prefix ou NamespaceURI para cada item, a cadeia de caracteres retornada será adicionada a um NameTable. A coleção mantida pelo NameTable nunca diminui de tamanho, criando um "vazamento de memória" virtual das alças de cadeia de caracteres.
Atenuantes incluem:
Derivar da classe NameTable e impor uma cota de tamanho máximo. (Você não pode impedir o uso de um NameTable ou alternar quando NameTable estiver cheio.)
Evite usar as propriedades mencionadas e, em vez disso, use o método MoveToAttribute com o método IsStartElement sempre que possível; esses métodos não retornam cadeias de caracteres e, portanto, evitam o problema de sobrecarregar a coleção NameTable.
Cliente mal-intencionado envia solicitações de licença excessivas para o serviço
Se um cliente mal-intencionado bombardear um serviço com solicitações excessivas de licença, isso poderá fazer com que o servidor use memória excessiva.
Mitigação: use as seguintes propriedades da classe LocalServiceSecuritySettings:
MaxCachedCookies: controla o número máximo de
SecurityContextTokens com limite de tempo que o servidor armazena em cache após a negociação deSPNegoouSSL.IssuedCookieLifetime: controla o tempo de vida do
SecurityContextTokensque o servidor emite após a negociação deSPNegoouSSL. O servidor armazena em cache osSecurityContextTokens para esse período.MaxPendingSessions: controla o número máximo de conversas seguras que são estabelecidas no servidor, mas para as quais nenhuma mensagem do aplicativo foi processada. Essa cota impede que os clientes estabeleçam conversas seguras no serviço, fazendo com que o serviço mantenha o estado por cliente, mas nunca as utilizem.
InactivityTimeout: controla o tempo máximo que o serviço mantém uma conversa segura ativa sem receber uma mensagem do aplicativo do cliente para a conversa. Essa cota impede que os clientes estabeleçam conversas seguras no serviço, fazendo com que o serviço mantenha o estado por cliente, mas nunca as utilizem.
WSDualHttpBinding ou associações personalizadas duplas exigem autenticação de cliente
Por padrão, o WSDualHttpBinding tem a segurança habilitada. No entanto, é possível que, se a autenticação do cliente estiver desabilitada definindo a propriedade ClientCredentialType como None, um usuário mal-intencionado poderá causar um ataque de negação de serviço a um terceiro serviço. Isso pode ocorrer porque um cliente mal-intencionado pode direcionar o serviço para enviar um fluxo de mensagens para um terceiro serviço.
Para mitigar isso, não defina a propriedade como None. Lembre-se também dessa possibilidade ao criar uma associação personalizada que tenha um padrão de mensagem dupla.
O log de eventos de auditoria pode ser preenchido
Se um usuário mal-intencionado entender que a auditoria está habilitada, esse invasor poderá enviar mensagens inválidas que fazem com que as entradas de auditoria sejam gravadas. Se o log de auditoria for preenchido dessa maneira, o sistema de auditoria falhará.
Para mitigar isso, defina a propriedade SuppressAuditFailure como true e use as propriedades do visualizador de eventos para controlar o comportamento de auditoria. Para obter mais informações sobre como usar o Visualizador de eventos para exibir e gerenciar logs de eventos, consulte Visualizador de eventos. Para obter mais informações, consulte Auditoria.
Implementações inválidas do IAuthorizationPolicy podem fazer com que o serviço não responda
Chamar o método Evaluate em uma implementação com falha da interface IAuthorizationPolicy pode fazer com que o serviço não responda.
Mitigação: use apenas código confiável. Ou seja, use apenas código que você escreveu e testou ou cuja origem seja um provedor confiável. Não permita que extensões não confiáveis de IAuthorizationPolicy sejam conectadas ao código sem a devida consideração. Isso se aplica a todas as extensões usadas em uma implementação de serviço. O WCF não faz distinção entre o código do aplicativo e o código estrangeiro conectado usando pontos de extensibilidade.
Pode ser necessário redimensionar o tamanho máximo do token Kerberos
Se um cliente pertencer a um grande número de grupos (aproximadamente 900, embora o número real varie dependendo dos grupos), um problema poderá ocorrer quando o bloco de um cabeçalho de mensagem exceder 64 quilobytes. Nesse caso, você pode aumentar o tamanho máximo do token Kerberos. Talvez você também precise aumentar o tamanho máximo da mensagem WCF para acomodar o token Kerberos maior.
Registro automático resulta em vários certificados com o mesmo nome da entidade para o computador
O registro automático é a funcionalidade do Windows Server 2003 de registrar automaticamente usuários e computadores para certificados. Quando um computador está em um domínio com o recurso habilitado, um certificado X.509 com a finalidade pretendida de autenticação de cliente é criado e inserido automaticamente no repositório de certificados pessoais do computador local sempre que um novo computador é ingressado na rede. No entanto, o registro automático usa o mesmo nome de entidade para todos os certificados que ele cria no cache.
O impacto é que os serviços WCF podem não ser abertos em domínios com registro automático. Isso ocorre porque os critérios de pesquisa de credencial X.509 de serviço padrão podem ser ambíguos, pois existem vários certificados com o nome DNS (Sistema de Nomes de Domínio) totalmente qualificado do computador. Um certificado é proveniente do registro automático; o outro pode ser um certificado com emissão automática.
Para atenuar isso, faça referência ao certificado exato a ser usado usando um critério de pesquisa mais preciso no <serviceCredentials>. Por exemplo, use a opção FindByThumbprint e especifique o certificado de acordo com sua impressão digital exclusiva (hash).
Para obter mais informações sobre o recurso de registro automático, consulte Registro automático de certificado no Windows Server 2003.
Último dos vários nomes de assunto alternativos usados para autorização
No caso raro em que um certificado X.509 contém vários nomes de assunto alternativos e você autoriza o uso do nome da entidade alternativa, a autorização pode falhar.
Proteger arquivos de configuração com ACLs
Você pode especificar declarações necessárias e opcionais em arquivos de código e configuração para tokens emitidos pelo CardSpace. Isso resulta em elementos correspondentes sendo emitidos em mensagens RequestSecurityToken que são enviadas para o serviço de token de segurança. Um invasor pode modificar o código ou a configuração para remover declarações necessárias ou opcionais, potencialmente fazendo com que o serviço de token de segurança emita um token que não permita o acesso ao serviço de destino.
Para mitigar: exija acesso ao computador para modificar o arquivo de configuração. Use ACLs (listas de controle de acesso a arquivos) para proteger arquivos de configuração. O WCF exige que o código esteja no diretório do aplicativo ou no cache de assembly global antes de permitir que esse código seja carregado da configuração. Use ACLs de diretório para proteger diretórios.
O número máximo de sessões seguras para um serviço é atingido
Quando um cliente é autenticado com êxito por um serviço e uma sessão segura é estabelecida com o serviço, o serviço mantém o controle da sessão até que o cliente cancele ou a sessão expire. Cada sessão estabelecida conta com relação ao limite para o número máximo de sessões simultâneas ativas com um serviço. Quando esse limite é atingido, os clientes que tentam criar uma nova sessão com esse serviço são rejeitados até que uma ou mais sessões ativas expirem ou sejam canceladas por um cliente. Um cliente pode ter várias sessões com um serviço e cada uma dessas sessões conta para o limite.
Observação
Quando você usa sessões com estado, o parágrafo anterior não se aplica. Para obter mais informações sobre sessões com estado, confira Como criar um token de contexto de segurança para uma sessão segura.
Para mitigar isso, defina o limite para o número máximo de sessões ativas e o tempo de vida máximo para uma sessão definindo a propriedade SecurityBindingElement da classe SecurityBindingElement.