Services Web sécurisés: REST sur HTTPS vs SOAP + WS-Security. Ce qui est mieux? [fermé]

Je ne suis en aucun cas un expert en sécurité, mais je préfère créer des services Web de style REST.

En créant un nouveau service qui a besoin de sécuriser les données qu'il transmet. Nous sommes entrés dans un débat sur l'approche la plus sécurisée - REST avec HTTPS ou SOAP WS avec WS-Security.

J'ai l'impression que nous pourrions utiliser HTTPS pour tous les appels de service Web et cette approche serait sécurisée. Selon moi, "si HTTPS est assez bon pour les sites Web bancaires et financiers, c'est assez bon pour moi". Encore une fois, je ne suis pas expert dans ce domaine, mais je pense que ces personnes ont beaucoup réfléchi à ce problème et sont à l'aise avec HTTPS.

Un collègue n'est pas d'accord et dit que SOAP et WS-Security sont la seule voie à suivre.

Le Web semble partout à ce sujet.

Peut-être que la communauté ici pourrait peser sur les avantages et les inconvénients de chacun? Merci!

HTTPS sécurise la transmission du message sur le réseau et fournit une certaine assurance au client sur l'identité du serveur. C'est ce qui est important pour votre banque ou votre courtier en valeurs mobilières en ligne. Leur intérêt à authentifier le client n'est pas dans l'identité de l'ordinateur, mais dans votre identité. Ainsi, les numéros de carte, les noms d'utilisateur, les mots de passe, etc. sont utilisés pour vous authentifier. Certaines précautions sont alors généralement prises pour s'assurer que les soumissions n'ont pas été falsifiées, mais dans l'ensemble, tout ce qui se passe pendant la session est considéré comme ayant été initié par vous.

WS-Security offre une protection de confidentialité et d'intégrité depuis la création du message jusqu'à sa consommation. Ainsi, au lieu de garantir que le contenu des communications ne peut être lu que par le bon serveur, cela garantit qu'il ne pourra être lu que par le bon processus sur le serveur. Au lieu de supposer que toutes les communications de la session initiée en toute sécurité proviennent de l'utilisateur authentifié, chacune doit être signée.

Il y a une explication amusante impliquant des motocyclistes nus ici:

https://docs.microsoft.com/archive/blogs/vbertocci/end-to-end-security-or-why-you-shouldnt-drive-your-motorcycle-naked

Ainsi, WS-Security offre plus de protection que HTTPS, et SOAP offre une API plus riche que REST. À mon avis, à moins que vous n'ayez vraiment besoin des fonctionnalités ou de la protection supplémentaires, vous devriez éviter la surcharge de SOAP et WS-Security. Je sais que c'est un peu une dérobade, mais les décisions sur le niveau de protection réellement justifié (pas seulement ce qui serait cool à construire) doivent être prises par ceux qui connaissent intimement le problème.

La sécurité REST dépend du transport, contrairement à la sécurité SOAP.

REST hérite des mesures de sécurité du transport sous-jacent tandis que SOAP définit les siens via WS-Security.

Lorsque nous parlons de REST, sur HTTP - toutes les mesures de sécurité appliquées HTTP sont héritées et c'est ce qu'on appelle la sécurité au niveau du transport.

Sécurité au niveau du transport, sécurise votre message uniquement lorsqu'il est sur le fil - dès qu'il quitte le fil, le message n'est plus sécurisé.

Mais, avec WS-Security, sa sécurité au niveau du message - même si le message quitte le canal de transport, il sera toujours protégé. De plus - avec la sécurité au niveau du message, vous pouvez chiffrer partiellement le message [pas le message entier, mais seulement les parties que vous voulez] - mais avec la sécurité au niveau du transport, vous ne pouvez pas le faire.

WS-Security a des mesures d'authentification, d'intégrité, de confidentialité et de non-répudiation tandis que SSL ne prend pas en charge la non-répudiation [avec OAuth en 2 étapes, c'est le cas].

En termes de performances, SSL est beaucoup plus rapide que WS-Security.

Merci...

Techniquement, la façon dont vous l'avez formulée n'est pas non plus correcte, car la communication de la méthode SOAP n'est pas sécurisée et la méthode REST n'a rien dit sur l'authentification des utilisateurs légitimes.

HTTPS empêche les attaquants d' écouter la communication entre deux systèmes. Il vérifie également que le système hôte (serveur) est en fait le système hôte auquel l'utilisateur a l'intention d'accéder.

WS-Security empêche les applications non autorisées (utilisateurs) d'accéder au système.

Si un système RESTful a un moyen d'authentifier les utilisateurs et qu'une application SOAP avec WS-Security utilise HTTPS, alors les deux sont vraiment sécurisés. C'est juste une manière différente de présenter et d'accéder aux données.

Voir l' article wiki :

Dans des situations point à point, la confidentialité et l'intégrité des données peuvent également être appliquées sur les services Web via l'utilisation de Transport Layer Security (TLS), par exemple en envoyant des messages via https.

WS-Security aborde cependant le problème plus large du maintien de l'intégrité et de la confidentialité des messages jusqu'à ce qu'un message ait été envoyé à partir du nœud d'origine, fournissant une sécurité dite de bout en bout.

C'est:

• HTTPS est un mécanisme de sécurité de la couche de transport (point à point)
• WS-Security est un mécanisme de sécurité de la couche application (de bout en bout).

Comme vous le dites, REST est assez bon pour les banques et devrait donc être assez bon pour vous.

La sécurité comporte deux aspects principaux: 1) le cryptage et 2) l'identité.

La transmission en SSL / HTTPS fournit un cryptage sur le fil. Mais vous devrez également vous assurer que les deux serveurs peuvent confirmer qu'ils savent à qui ils parlent. Cela peut se faire via des certificats clients SSL, des secrets partagés, etc.

Je suis sûr que l'on pourrait faire valoir que SOAP est "plus sûr" mais probablement pas de manière significative. L'analogie du motocycliste nu est mignonne, mais si elle est exacte, cela impliquerait que tout Internet n'est pas sécurisé.

Je n'ai pas encore le représentant nécessaire pour ajouter un commentaire ou je l'aurais simplement ajouté à la réponse de Bell. Je pense que Bell a fait un très bon travail en résumant les avantages et les inconvénients de ces deux approches. Juste quelques autres facteurs que vous voudrez peut-être prendre en compte:

1) Les demandes entre vos clients et votre service doivent-elles passer par des intermédiaires qui nécessitent un accès à la charge utile? Si tel est le cas, WS-Security pourrait être une meilleure solution.

2) Il est en fait possible d'utiliser SSL pour fournir au serveur l'assurance de l'identité des clients en utilisant une fonction appelée authentification mutuelle. Cependant, cela n'est pas beaucoup utilisé en dehors de certains scénarios très spécialisés en raison de la complexité de sa configuration. Bell a donc raison de dire que WS-Sec est un bien meilleur choix ici.

3) SSL en général peut être un peu difficile à installer et à maintenir (même dans la configuration la plus simple) en raison principalement de problèmes de gestion des certificats. Avoir quelqu'un qui sait comment faire cela pour votre plateforme sera un gros plus.

4) Si vous devez effectuer une forme de mappage des informations d'identification ou de fédération d'identité, WS-Sec peut valoir la peine. Non pas que vous ne puissiez pas faire cela avec REST, vous avez juste moins de structure pour vous aider.

5) Mettre tout le goop WS-Security aux bons endroits du côté client peut être plus pénible que vous ne le pensez.

En fin de compte, cela dépend vraiment de beaucoup de choses que nous ne saurons probablement pas. Pour la plupart des situations, je dirais que l'une ou l'autre approche sera «suffisamment sûre» et que cela ne devrait donc pas être le principal facteur décisif.

Brace yourself, here there's another coming :-)

Aujourd'hui, j'ai dû expliquer à ma copine la différence entre le pouvoir expressif de WS-Security par rapport à HTTPS. Elle est informaticienne, donc même si elle ne connaît pas tout le mumbo jumbo XML, elle comprend (peut-être mieux que moi) ce que signifie le cryptage ou la signature. Cependant je voulais une image forte, qui pourrait lui faire vraiment comprendre à quoi servent les choses, plutôt que comment elles sont implémentées (cela est venu un peu plus tard, elle n'y a pas échappé :-)).

Alors ça va comme ça. Supposons que vous soyez nu et que vous deviez conduire votre moto jusqu'à une certaine destination. Dans le cas (A), vous passez par un tunnel transparent: votre seul espoir de ne pas être arrêté pour comportement obscène est que personne ne regarde. Ce n'est pas exactement la stratégie la plus sûre que vous puissiez adopter ... (remarquez la sueur qui tombe du front du gars :-)). Cela équivaut à un POST en clair, et quand je dis «équivalent», je le pense. Dans le cas (B), vous êtes dans une meilleure situation. Le tunnel est opaque, donc tant que vous y voyagez, votre dossier public est en sécurité. Cependant, ce n'est toujours pas la meilleure situation. Vous devez toujours quitter la maison et atteindre l'entrée du tunnel, et une fois à l'extérieur du tunnel, vous devrez probablement descendre et marcher quelque part ... et cela vaut pour HTTPS. Vrai, votre message est en sécurité lorsqu'il traverse le plus grand gouffre: mais une fois que vous l'avez livré de l'autre côté, vous ne savez pas vraiment combien d'étapes il devra passer avant d'atteindre le point réel où les données seront traitées. Et bien sûr, toutes ces étapes pourraient utiliser quelque chose de différent de HTTP: un MSMQ classique qui met en mémoire tampon les requêtes qui ne peuvent pas être servies immédiatement, par exemple. Que se passe-t-il si quelqu'un cache vos données alors qu'il se trouve dans les limbes du prétraitement? Hm. (lisez ce "hm" comme celui prononcé par Morpheus à la fin de la phrase "pensez-vous que c'est de l'air que vous respirez?"). La solution complète (c) dans cette métaphore est douloureusement anodine: mettez-vous des vêtements sacrés sur vous-même, et surtout le casque sur la moto !!! Vous pouvez donc vous déplacer en toute sécurité sans avoir à vous fier à l'opacité des environnements. La métaphore est, espérons-le, claire: les vêtements vous accompagnent indépendamment de la moyenne ou de l'infrastructure environnante, comme le fait la sécurité au niveau du message. De plus, vous pouvez décider de couvrir une partie mais en révéler une autre (et vous pouvez le faire sur une base personnelle: la sécurité de l'aéroport peut enlever votre veste et vos chaussures, tandis que votre médecin peut avoir un niveau d'accès plus élevé), mais rappelez-vous que les chemises à manches courtes sont mauvaise pratique même si vous êtes fier de vos biceps :-) (mieux un polo, ou un t-shirt).

Je suis heureux de dire qu'elle a compris! Je dois dire que la métaphore du vêtement est très puissante: j'ai été tenté de l'utiliser pour introduire le concept de politique (les discothèques ne vous laisseront pas porter de chaussures de sport; vous ne pouvez pas aller retirer de l'argent dans une banque en sous-vêtements , alors que c'est un look parfaitement acceptable tout en vous équilibrant sur un surf; et ainsi de suite) mais je pensais que pour un après-midi c'était suffisant ;-)

Architecture - WS, idées sauvages

Avec l'aimable autorisation: http://blogs.msdn.com/b/vbertocci/archive/2005/04/25/end-to-end-security-or-why-you-shouldn-t-drive-your-motorcycle-naked. aspx

Je travaille dans cet espace tous les jours, je veux donc résumer les bons commentaires à ce sujet dans le but de clore cela:

SSL (HTTP / s) n'est qu'une couche assurant:

1. Le serveur auquel se connecter présente un certificat prouvant son identité (bien que cela puisse être usurpé par empoisonnement DNS).
2. La couche de communication est cryptée (pas d'écoute clandestine).

WS-Security et les normes / implémentations associées utilisent une PKI qui:

1. Prouvez l'identité du client.
2. Prouvez que le message n'a pas été modifié en transit (MITM).
3. Permet au serveur d'authentifier / d'autoriser le client.

Le dernier point est important pour les demandes de service lorsque l'identité du client (appelant) est primordiale pour savoir s'il doit être autorisé à recevoir de telles données du service. Le SSL standard est une authentification unidirectionnelle (serveur) et ne fait rien pour identifier le client.

La réponse dépend en fait de vos besoins spécifiques.

Par exemple, avez-vous besoin de protéger vos messages Web ou la confidentialité n'est pas requise et tout ce dont vous avez besoin est d'authentifier les parties finales et d'assurer l'intégrité des messages? Si tel est le cas - et c'est souvent le cas avec les services Web - HTTPS est probablement le mauvais marteau.

Cependant, d'après mon expérience, ne négligez pas la complexité du système que vous construisez. Non seulement HTTPS est plus facile à déployer correctement, mais une application qui repose sur la sécurité de la couche de transport est plus facile à déboguer (sur HTTP simple).

Bonne chance.

REST sur HTTPS Doit être une méthode sécurisée tant que le fournisseur d'API implémente l'autorisation à l'extrémité du serveur. Dans le cas d'une application Web, nous accédons également à une application Web via HTTPS et à une authentification / autorisation, les applications Web n'avaient traditionnellement pas de problèmes de sécurité, alors Restful API permettrait également de contrer les problèmes de sécurité sans problème!

Si votre appel RESTFul envoie des messages XML dans les deux sens intégrés dans le corps Html de la requête HTTP, vous devriez pouvoir bénéficier de tous les avantages de WS-Security tels que le cryptage XML, les certificats, etc. dans vos messages XML tout en utilisant les fonctionnalités de sécurité. sont disponibles sur http comme le cryptage SSL / TLS.