La sécurité des Web Services SOAP

Il y a deux types de besoins de sécurité.

• Les besoins liés aux spécifications de l'application et au niveau de sensibilité du ou des services exposés. On parle ici de sécurité fonctionnelle.
• Les besoins liés aux technologies employées, à leur degré de vulnérabilité face aux menaces. On parle ici de sécurité technique.

La sécurité fonctionnelle

• Quel doit être le comportement du service en cas d'erreur ?
• Quel est le niveau de confidentialité des informations véhiculées ?
• Est-il nécessaire de garantir l'authenticité de informations ?
• Doit-on être authentifié pour accéder au service ?
• Doit-on donner des rôles différents aux différents systèmes qui utilisent le service ?
• Doit-on faire la différence entre retransmission d'une requête et le renouvellement volontaire de la même requête par un client hostile ?
• Doit-on tenir compte de enchaînement des webservices ?

Des solutions sont proposées afin de répondre à ces problématiques. Il s'agit d’extensions à la norme SOAP:

• XML Encryption
• XML Signature
• SAML

XML Encryption

Pour répondre aux questions concernant la confidentialité des données, on peut chiffrer des portions de la requête SOAP. Un message SAOP peut être comporter plusieurs portions chiffrées avec des clés différentes.

XML Signature

En signant le document, on associe l'identité de l'émetteur au document  soap envoyé. Cela permet de garantir l'intégrité du document, ou d'un portion de celui-ci. De cette façon, toute modification du document est aussitôt détectée. Cela permet aussi d'attribuer telle donnée à tel utilisateur. Ce mécanisme répond aux problèmes du traitement de l'intégrité des données, de leur authenticité, ainsi que de la traçabilité et de l'imputabilité.

SAML (Security assertion markup language)
Ce mécanisme crée des jetons sécurisés qui permettent la propagation d'informations d'identité et d’autorisation pour un utilisateur.

Autres problèmes
- SOAP ne limite pas la taille des messages. Quelqu'un de mal intentionné peut envoyer un message énorme. Ce dernier sera chargé entièrement par le parseur DOM, causant ainsi un déni de service (DoS).
- Pour la validation des messages, il est judicieux d'employer un XSD plutôt qu'un DTD. En effet, l'adresse du DTD étant écrit directement dans le message, quelqu'un qui intercepte le messagez pourra la modifier pour qu'elle pointe vers sa DTD. Alors qu'avec XSD, seul le serveur sait quel XSD utiliser pour valider le contenu.
- De même qu'il y a l'injection SQL, le parsing XPath est vulnérable à l'injection du même nom. 
- Pour tenter de réusoudre ces problèmes, la première chose à faire est d'utiliser un framework adapté. C'est une solution éprouvée et testée, qui a fait ses preuves. Cela ne sert à rien de déveloper son propre parseur, au risque d'oublier de nombreuses failles potentielles.

La sécurité technique

Les messages échangés, même sécurisé par les mécanismes que nous venons de voir, transitent sur tous les composants constituant le réseau. Cela va des couches TCP/IP à la structure même du message SOAP. Chacune de ces couches est vulnérable.

Concernant les vulnérabilité au niveau SOAP et XML:

• L'annuaire de webservice, UDDI, facilite la recherche de services privée.
• WS-Routing permet au client de spécifier le routage vers des services non exposés. De ce fait, il donne la possibilité de trouver les systèmes accessibles du service frontal.
• WS-Security : En construisant des boucles de référencement mutuelle, on arrive à des dénis de services.
• La modification des structures de données touchent aussi aux mécanismes WS-Security.
• L'encodage multiple du message peut entraîner une surcharge du serveur.

En réponse à ces problème liés:

• On peut commencer par ne pas employer WS-Routing, mais utiliser une mécanisme plus sécurisé, tel WS-Addressing. 
• Utiliser un pare-feu XML pour vérifier que chaque requête reçue est autorisé, que le message est bien structuré et conforme, qu'il ne comporte pas de code malveillant en se basant sur des signatures connues.
• En controlant en amont du webservice les droit d'accès. Cela peut se faire en se basant sur le jeton SAML présent dans le message.

Pour ce qui est des failles de niveau HTTP:

• Des requêtes mal formées ou trop complexes peuvent générer  un déni de service ou permettre des attaques par débordement de mémoire.
• L'URL employée pour accèder au webservice permet aussi de joindre tous les services gérés par le moteur SOAP.

Pour tenter d'apporter une solution à ces problèmes:

• Il convient d'utiliser un pare-feu en amont des webservices pour filter l'accès aux seuls services exposés.
• Cloisonner les webservices du reste du système d'information pour limiter son accessibilité indirecte via les services exposés.
• Garantir l'intégrité et la confidentialité des requêtes en utilisant SSL/TLS.  Cela permet une authentification des clients et des serveurs.
• Utiliser HTTPS pour exposer ses services n’empêche pas tous les risques. Cela protège la confidentialité du message contre les interceptions. Mais toutes les autres attaques restent possibles.