Vulnérabilités de sécurité de POST over SSL
Je travaille pour une petite entreprise, développant une application web ASP.NET. Récemment, nous avons eu l'obligation d'exposer un point de terminaison d'API, de sorte qu'un script automatisé exécuté dans le cloud puisse périodiquement retirer certaines données au format JSON de l'application via une demande Web. Je peux gérer la mise en œuvre de cela, mais je n'étais pas sûr des problèmes de sécurité. Je lisais sur HMAC ce matin et j'aimais son apparence, car elle semblait assez similaire aux protocoles de sécurité des autres API que j'ai utilisées précédemment. Cependant, cela m'a fait me demander quelle était la valeur de certaines étapes.
Si un client et un serveur se sont mis d'accord sur une phrase de passe/clé en toute sécurité via une communication préalable, quel risque y a-t-il à envoyer une demande POST avec la phrase de passe dans le corps de la demande HTTPS, de sorte que la phrase de passe identifie l'utilisateur? En essayant de chercher cela, je suis tombé sur des attaques de relecture et similaires, mais ces opérations peuvent-elles être effectuées sur SSL et étant donné que les environnements côté client et côté serveur peuvent être fiables?
Edit: Ajout d'un peu de clarification basé sur le commentaire d'un utilisateur ci-dessous. Notre cas d'utilisation prévu est d'exécuter un script périodiquement (une fois par heure, jour, etc.) sur l'un de nos serveurs ou dans le cloud. Il récupérera des informations spécifiques de notre application, ainsi que des API tierces, et mettra à jour une feuille de calcul basée sur le cloud pour notre équipe de développement commercial. C'est quelque chose que nous souhaitons idéalement laisser fonctionner et ne nécessiter aucune intervention de l'utilisateur. Notre application nécessite normalement une connexion avec un nom d'utilisateur/mot de passe pour générer une session temporaire, mais nous espérions simplifier un peu le processus et simplement fournir une API pour que le script récupère en toute sécurité des données spécifiques.
En supposant que vous voulez dire TLS au lieu de SSL authentique (qui est beaucoup plus ancien et cassé), il est tout à fait correct de transmettre le mot de passe dans une demande POST. Ceci est standard et comment pratiquement chaque site Web majeur et sécurisé le service d'authentification fonctionne. Il vous suffit de vous assurer que le TLS est correctement configuré. TLS atténue toutes les attaques qui vous inquiètent. Il utilise HMAC (ou une authentification similaire) pour l'intégrité, et atténue les attaques de relecture, les attaques par réflexion et les problèmes similaires qui affectent les systèmes d'authentification.
HTTPS sert à plusieurs fins, empêchant les attaques de relecture et assurant la confidentialité du message envoyé. Pour respecter ces garanties, le client doit bien sûr vérifier correctement le certificat TLS du serveur, c'est-à-dire faire correspondre le certificat avec le domaine attendu (ou si vous avez des certificats auto-signés, avec une empreinte digitale). Sinon, une attaque d'homme au milieu peut avoir lieu sans que l'une ou l'autre extrémité ne s'en aperçoive. De cette façon, le client sait qu'il parle vraiment au bon serveur.
Mais comment le serveur peut-il faire confiance au client? Pour cela, vous pouvez utiliser soit un certificat client, soit, comme vous le proposez, une clé API. Les clés API sont un concept commun, donc s'il y avait un gros problème avec cela, nous aurions cessé de le faire maintenant. C'est une bonne pratique de renouveler régulièrement une clé API et il peut être pratique d'avoir un champ ID de clé pour pouvoir les faire pivoter facilement, mais généralement cela ne devrait pas être un gros risque d'utiliser la même clé pendant des années - bien sûr, cela dépend de la sensibilité de l'information, du nombre de personnes ayant accès à la clé, etc.