Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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 extremamente lentamente.
Consumo excessivo de memória
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 as propriedades 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.
As mitigações incluem:
Derive da classe NameTable e estabeleça uma cota máxima de tamanho. (Você não pode impedir o uso de um NameTable ou alternar o NameTable quando ele estiver cheio.)
Evite usar as propriedades mencionadas e, em vez disso, use o MoveToAttribute método com o IsStartElement método sempre que possível; esses métodos não retornam cadeias de caracteres e, portanto, evitam o problema de preenchimento excessivo da NameTable coleção.
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 de licença excessivas, isso poderá fazer com que o servidor use memória excessiva.
Mitigação: use as seguintes propriedades da LocalServiceSecuritySettings classe:
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 de tempo.MaxPendingSessions: controla o número máximo de conversas seguras estabelecidas no servidor, mas para as quais nenhuma mensagem de 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 de 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, a segurança do WSDualHttpBinding está habilitada. No entanto, é possível que, se a autenticação do cliente estiver desabilitada definindo a ClientCredentialType propriedade como None, um usuário mal-intencionado poderá causar um ataque de negação de serviço em 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 atenuar 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 atenuar isso, defina a SuppressAuditFailure propriedade 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 o Visualizador de Eventos. Para obter mais informações, veja Auditoria.
Implementações inválidas do IAuthorizationPolicy podem fazer com que o serviço não responda
Chamar o Evaluate método em uma implementação com falha da IAuthorizationPolicy interface pode fazer com que o serviço não responda.
Mitigação: use apenas o código confiável. Ou seja, use apenas o código que você escreveu e testou ou que venha de um provedor confiável. Não permita que extensões não confiáveis de IAuthorizationPolicy sejam inseridas no 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 nenhuma distinção entre o código do aplicativo e o código estrangeiro conectado usando pontos de extensibilidade.
O tamanho máximo do token Kerberos pode precisar de redimensionamento
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 capacidade 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 do WCF podem não abrir em domínios com o registro automático. Isso ocorre porque os critérios de pesquisa de credenciais X.509 do serviço padrão podem ser ambíguos porque existem vários certificados com o nome DNS (Sistema de Nomes de Domínio) totalmente qualificado do computador. Um certificado é originário do registro automático; o outro pode ser um certificado auto-emitido.
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 por 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 obrigató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 obrigató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 atenuar: 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 requer 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.
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, consulte Como criar um token de contexto de segurança para uma sessão segura.
Para atenuar isso, defina o limite para o número máximo de sessões ativas e o tempo máximo de vida de uma sessão definindo a SecurityBindingElement propriedade da SecurityBindingElement classe.