Considerações de Segurança para Serviços da Web

Quando você configura o Web Services Security, deverá fazer cada esforço para verificar se o resultado não é vulnerável a uma ampla variedade de mecanismos de ataques. Há possíveis questões de segurança que surgem quando você protege os serviços da Web.

No WebSphere Application Server, quando você ativa a integridade, a confidencialidade e os tokens associados em uma mensagem SOAP, a segurança não é garantida. Essa lista de preocupações com a segurança não está completa. É necessário conduzir sua própria análise de segurança para seu ambiente.

  • Assegurando a Atualização da Mensagem
    A atualização da mensagem envolve a proteção de recursos de um ataque de reprodução no qual uma mensagem é capturada e reenviada. As próprias assinaturas digitais não podem prevenir um ataque de reprodução, porque uma mensagem assinada pode ser capturada e reenviada. É recomendável permitir que os destinatários da mensagem detectem os ataques de reprodução da mensagem quando as mensagens são trocadas por meio de uma rede aberta. É possível usar os seguintes elementos, que estão descritos nas especificações do Web Services Security, para essa finalidade:
    Registro de Data e Hora
    É possível usar o elemento time stamp para fazer o acompanhamento de mensagens e para detectar reproduções de mensagens anteriores. A especificação WS-Security 2004 recomenda armazenar em cache time stamps por um período de tempo especificado. Como diretriz, é possível usar cinco minutos como um período de tempo mínimo para detectar reproduções. As mensagens que contêm um time stamp expirado são rejeitadas.
    Nonce
    Um nonce é um elemento filho do elemento <UsernameToken> no perfil UsernameToken. Como cada elemento nonce possui um valor exclusivo, os destinatários podem detectar ataques de reprodução com relativa facilidade.
    Evitar Problemas Evitar Problemas: Para obter o máximo de segurança contra os ataques de reprodução usando o requisito de Registro de data e hora, os elementos Registro de data e hora e Nonce devem ser assinados. Caso contrário, estes elementos podem ser facilmente alterados e, portanto, não podem prevenir ataques de reprodução.gotcha

    Para obter mais informações sobre registro de data e hora, consulte Registro de data e hora.

    O WebSphere Application Server impinge a asserção de política IncludeTimestamp. No entanto, vários provedores de serviços requerem este elemento <wsu:Timestamp> na solicitação, mas não enviam um na resposta. Também há a possibilidade de não haver nenhum cabeçalho de segurança na resposta, muito menos um registro de data e hora. O seguinte erro ocorrerá em um cliente quando IncludeTimestamp estiver na política, mas nenhum registro de data e hora for retornado na resposta:
    CWWSS5730E: Um registro de data e hora requerido não foi localizado.
    Para resolver o problema, configure o provedor de serviços para enviar um registro de data e hora ou configure o cliente para não requerer o registro de data e hora, configurando a propriedade customizada para com.ibm.wsspi.wssecurity.consumer.timestampRequired false nas ligações de política de Segurança WS. Para obter informações adicionais, consulte Propriedades Customizadas de Segurança de Serviços da Web.
  • Utilizando a Assinatura Digital XML e a Criptografia XML Corretamente para Evitar uma Possível Falha na Segurança

    A especificação do Web Services Security 2004 define como usar assinatura digital XML e criptografia XML nos cabeçalhos SOAP. Portanto, os usuários devem entender a assinatura digital XML e criptografia XML no contexto dos outros mecanismos de segurança e suas possíveis ameaças a uma entidade. Para uma assinatura digital XML, é necessário estar ciente de todas as implicações de segurança resultantes do uso de assinaturas digitais em geral e de assinatura digital XML em específico. Quando construir a confiança para um aplicativo com base em uma assinatura digital, é necessário incorporar outras tecnologias, tais como, validação de confiança de certificação com base na PKI (Infra-estrutura da Chave Pública). Para criptografia XML, a combinação de assinatura digital e de criptografia sobre um item de dados comum pode introduzir algumas vulnerabilidades criptográficas. Por exemplo, quando você criptografar dados assinados digitalmente, poderá deixar a assinatura digital em texto corrido e deixar sua mensagem vulnerável a ataques de violação de texto corrido. Como prática geral, quando os dados forem criptografados, criptografe cada compilação ou assinatura sobre os dados. Para obter informações adicionais, consulte http://www.w3.org/TR/xmlenc-core/#sec-Sign-with-Encrypt.

  • Protegendo a Integridade de Tokens de Segurança

    Existe a possibilidade de um ataque de substituição de token. Neste cenário, uma assinatura digital é verificada com uma chave que geralmente é derivada de um token de segurança e está incluída em uma mensagem. Se o token for substituído, um destinatário poderá aceitar a mensagem com base na chave substituída, que pode não ser o que você espera. Uma possível solução para este problema é assinar o token de segurança (ou a identificação exclusiva de dados a partir da qual a chave de assinatura é derivada) junto com os dados assinados. Em algumas situações, o token emitido por uma autoridade confiável é assinado. Neste caso, pode não haver um problema de integridade. No entanto, como a semântica do aplicativo e o ambiente podem se alterar com o tempo, a prática recomendável é prevenir este ataque. É necessário fazer a avaliação do risco com base no ambiente implementado.

  • Verificando o Certificado para Tirar Proveito da Verificação de Caminho do Certificado e a CRL (Certificate Revocation List)

    É recomendável verificar se a autenticidade ou validade da identidade do token utilizado para assinatura digital é apropriadamente confiável. Principalmente para um token X.509, este problema envolve a verificação do caminho do certificado e o uso de uma CRL (Certificate Revocation List). Na implementação do Web Services Security no WebSphere Application Server Versão 6 e superior, o certificado é verificado pelo elemento <TokenConsumer>. O WebSphere Application Server fornece uma implementação padrão para o certificado X.509 que utiliza a biblioteca CertPath Java™ para verificar e validar o certificado. Na implementação, não há nenhum conceito explícito de uma CRL. Em vez disso, os certificados raiz e os certificados intermediários apropriados são preparados apenas em arquivos. Para uma solução sofisticada, você pode desenvolver sua própria implementação do TokenConsumer que executa a verificação do certificado e da CRL utilizando o banco de dados da CRL on-line ou o OCSP (Online Certificate Status Protocol).

  • Protegendo o Token do Nome do Usuário com uma Senha

    É recomendável não enviar uma senha em um token de nome de usuário para um servidor de recebimento de dados sem proteção. É possível usar a segurança no nível de transporte, como SSL (por exemplo, HTTPS) ou usar a criptografia XML no Web Services Security para proteger a senha. O método preferencial de proteção depende de seu ambiente. No entanto, é possível enviar uma senha para um servidor de recebimento de dados como texto corrido em alguns ambientes especiais, nos quais você tem certeza de que não está vulnerável a um ataque.

Proteger os serviços da Web envolve mais trabalho do que apenas ativar a assinatura digital XML e a criptografia XML. Para proteger corretamente um serviço da Web, é necessário ter conhecimento sobre a PKI. A quantidade de segurança necessária depende do ambiente implementado e dos padrões de uso. Entretanto, há algumas regras básicas e boas práticas para proteger os serviços da Web. É recomendável ler alguns manuais sobre PKI e também informações sobre o BSP (Basic Security Profile) de WS-I (Web Services Interoperability Organization).


Ícone que indica o tipo de tópico Tópico de Referência



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rwbs_secconsider6wssec
Nome do arquivo: rwbs_secconsider6wssec.html