Considérations liées à la sécurité des services Web

Lorsque vous configurez WS-Security, vous devez mettre tout en oeuvre pour vérifier que le résultat ne peut pas faire l'objet d'attaques diverses. Des problèmes de sécurité peuvent survenir lors de la sécurisation des services Web.

Dans WebSphere Application Server, la sécurité n'est pas garantie lorsque vous activez les fonctions d'intégrité, de confidentialité et les jetons associés dans un message SOAP. La liste des questions de sécurité n'est pas exhaustive. Vous devez effectuer votre propre analyse de votre environnement.

  • Vérifier que le message est récent.
    Cette vérification implique la protection des ressources contre une attaque de réexécution (replay) au cours de laquelle un message est capturé et renvoyé. Les signatures numériques ne peuvent pas empêcher ce type d'attaque car un message signé peut être capturé et renvoyé. Il est recommandé d'autoriser les destinataires des messages à détecter les attaques de réexécution lorsque des messages sont échangés via un réseau ouvert. Pour ce faire, vous pouvez utiliser les éléments suivants, qui sont décrits dans les spécifications WS-Security :
    Timestamp
    Vous pouvez utiliser l'élément timestamp pour suivre les messages et détecter les attaques de réexécution (replay) de messages antérieurs. La spécification WS-Security 2004 recommande de placer les horodatages en mémoire cache pendant une période donnée. A titre d'exemple, vous pouvez appliquer un délai de cinq minutes pour détecter les attaques de réexécution (replay). Les messages dotés d'un horodatage arrivé à expiration sont rejetés.
    Nonce
    Un nonce est un élément enfant du jeton <UsernameToken> dans le profil UsernameToken. Chaque élément Nonce possédant une valeur unique, les destinataires peuvent détecter relativement facilement les attaques de réexécution (replay).
    Eviter les incidents Eviter les incidents: Afin d'optimiser la sécurité en cas d'attaques de réexécution à l'aide de l'exigence Timestamp, les éléments Timestamp et Nonce doivent être signés. Dans le cas contraire, ils peuvent être facilement modifiés et ne peuvent plus empêcher les attaques de réexécution (replay).gotcha

    Pour plus d'informations sur Timestamp, voir Time stamp.

    WebSphere Application Server impose l'assertion de règle IncludeTimestamp. Toutefois, de nombreux fournisseurs de services exigent l'élément <wsu:Timestamp> dans la demande mais n'envoient pas cet élément dans la réponse. Il est aussi possible qu'il n'y ait aucun en-tête de sécurité ou horodatage dans la réponse. L'erreur suivante se produira sur un client quand IncludeTimestamp est inclus dans la règle alors qu'aucun horodatage n'est retourné dans la réponse :
    CWWSS5730E: Un horodatage requis est introuvable.
    Pour résoudre le problème, configurez le fournisseur de service pour envoyer un horodatage ou bien configurez le client pour qu'il ne demande pas l'horodatage en définissant à false la propriété personnalisée com.ibm.wsspi.wssecurity.consumer.timestampRequired dans les liaisons de règle WS-Security. Pour plus d'informations, voir Propriétés personnalisées de la sécurité des services Web.
  • Utilisation d'une signature numérique XML et du chiffrement XML pour éviter une faille dans la sécurité

    La spécification Web Services Security 2004 indique comment utiliser la signature numérique XML et le chiffrement XML dans les en-têtes SOAP. Les utilisateurs doivent donc comprendre le fonctionnement de la signature numérique XML et du chiffrement XML dans le contexte d'autres mécanismes de sécurité et les menaces possibles pour une entité. Dans le cas d'une signature numérique XML, vous devez comprendre toutes les implications liées à l'utilisation de signatures numériques en général et de la signature numérique XML en particulier. Lorsque vous établissez une relation de confiance dans une application en utilisant une signature numérique, vous devez intégrer d'autres technologies, telles qu'une validation de la relation de confiance par certification à l'aide du mécanisme PKI (Public Key Infrastructure). Pour le chiffrement XML, l'association d'une signature numérique et du chiffrement pour des données standard peuvent représenter un danger. Par exemple, lorsque vous chiffrez des données associées à une signature numérique, vous pouvez ne pas chiffrer la signature numérique et rendre le message vulnérable en cas d'attaques. En règle générale lorsque des données sont chiffrées, chiffrez également les messages de synthèse ou les signatures. Pour plus d'informations, voir http://www.w3.org/TR/xmlenc-core/#sec-Sign-with-Encrypt.

  • Protection de l'intégralité des jetons de sécurité

    Il existe toujours un risque d'attaque avec substitution des jetons. Dans ce scénario, une signature numérique est vérifiée avec une clé définie à partir d'un jeton de sécurité et est incluse dans un message. Si le jeton est remplacé, un destinataire risque d'accepter le message associé à la clé remplacée et de ne pas obtenir ce qu'il attendait. L'une des solutions possibles est de signer le jeton de sécurité (ou les données d'identification uniques à partir desquelles la clé de signature est établie) avec les données signées. Dans certaines situations, le jeton émis par l'autorité habilitée est signé. Dans ce cas, il est possible que l'intégrité soit préservée. Toutefois, comme la sémantique de l'application et l'environnement peuvent évoluer avec le temps, la meilleure solution est d'éviter l'attaque. Vous devez évaluer le risque en fonction de l'environnement déployé.

  • Vérification du certificat avec la vérification du chemin du certificat et l'utilisation de listes de révocation de certificats

    Il est recommandé de vérifier si l'authenticité ou la validité de l'identité du jeton utilisée pour la signature numérique est digne de confiance. Pour les jetons X.509, cette procédure implique la vérification du chemin du certificat et l'utilisation d'une liste de révocation des certificats (CRL). Dans l'implémentation de la sécurité des Services Web de WebSphere Application Server version 6 et ultérieure, le certificat est vérifié par l'élément <TokenConsumer>. WebSphere Application Server fournit une implémentation par défaut pour le certificat X.509 qui utilise la bibliothèque Java™ CertPath pour vérifier et valider le certificat. Dans l'implémentation, le concept de liste de révocation de certificats n'existe pas de manière explicite. Des certificats racine appropriés et des certificats intermédiaires sont préparés uniquement dans des fichiers. Si vous souhaiter mettre en place une solution plus élaborée, vous pouvez développer votre propre implémentation TokenConsumer qui effectue la vérification des certificats et des listes de révocation des certificats à l'aide de la base de données CRL en ligne ou du protocole OCSP (Online Certificate Status Protocol).

  • Protection du jeton Nom d'utilisateur avec un mot de passe

    Il est recommandé de ne pas envoyer à un serveur en aval un mot de passe dans un jeton username sans protection. Vous pouvez utiliser la sécurité au niveau transport (par exemple, HTTPS) ou utiliser le chiffrement XML de WS-Security pour protéger le mot de passe. La méthode de protection à appliquer varie en fonction de votre environnement. Toutefois, vous pouvez envoyer un mot de passe à un serveur en aval sous la forme d'un texte normal si vous vous trouvez dans des environnements particuliers où vous êtes certain que vous ne pouvez pas être attaqué.

La sécurisation des services Web implique beaucoup plus de tâches que la simple activation de la signature numérique XML et du chiffrement XML. Pour sécuriser correctement un service Web, vous devez connaître le mécanisme PKI (Public Key Infrastructure). Le niveau de sécurité dont vous avez besoin varie en fonction de l'environnement déployé et du mode d'utilisation. Toutefois, il existe des règles de base et des procédures recommandées pour sécuriser les services Web. Il est recommandé de lire des ouvrages sur PKI et de s'informer sur le profil BSP (Basic Security Profile) WS-I (Web Services Interoperability Organization).


Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rwbs_secconsider6wssec
Nom du fichier : rwbs_secconsider6wssec.html