Connexion sécurisée entre le client et le serveur

Question

Je suis en train de développer un composant serveur qui servira les requêtes pour un client intégré, qui est également sous mon contrôle.

En ce moment, tout est bêta et la sécurité fonctionne comme ceci:

1. client envoie le nom d'utilisateur/mot de passe via https.

2. Le serveur renvoie le jeton d'accès.

3. Le client effectue d'autres requêtes sur http avec le jeton d'accès dans un en-tête personnalisé.

Ceci est très bien pour une démo, mais il a quelques problèmes qui doivent être fixés avant de le relâcher:

• Tout le monde peut copier une demande login, le renvoyer et obtenir un retour d'un jeton. Comme certains utilisateurs ont répondu ce n'est pas un problème car il va sur https. Mon erreur. N'importe qui peut écouter et obtenir une clé d'accès simplement en inspectant les en-têtes de demande.

Je peux penser à un chiffrement à clé symétrique, avec un horodatage donc je peux rejeter les demandes en double, mais je me demandais s'il y a pour ce scénario (qui semble un peu commun) quelques bonnes pratiques bien connues.

Merci beaucoup pour votre avis. PS: J'utilise Java pour le serveur et le client est codé en C++, juste au cas où.

Answer 1

Je ne reçois pas la première partie, Si la demande de connexion est https, comment quelqu'un peut-il simplement le copier? Concernant la deuxième partie, t Il s'agit d'un scénario de détournement de session assez standard. Voir this question. Bien sûr, vous n'avez pas les options de navigateur intégrées ici, mais l'idée de base est la même: soit envoyer le jeton uniquement via une connexion sécurisée quand cela est important, soit associer le jeton à l'appareil émetteur. Dans un navigateur, tout ce que vous avez est essentiellement une adresse IP (ce qui n'est pas très bon), mais dans votre cas, vous pouvez exprimer quelque chose de spécifique à votre appareil que vous validez par rapport à la requête pour assurer le même jeton n'est pas utilisé d'ailleurs. Edit: Vous pourriez juste être chanceux ici et être en mesure d'exclure l'adresse IP changeant derrière les proxies, et de l'utiliser réellement à cette fin.

Mais à la fin de la journée, il est beaucoup plus sûr d'utiliser https d'une bibliothèque bien connue et révisée plutôt que d'essayer de rouler votre propre ici. Je me rends compte que https est un overhead, mais rouler le vôtre a de gros risques de manquer des choses évidentes qu'un attaquant peut exploiter.

Answer 2

L'une des recommandations communes est - utiliser https

homme https dans l'attaque du milieu de côté en utilisant https pour toute la session doit être suffisamment fiable. Vous n'avez même pas besoin de vous inquiéter des jetons d'accès - https prend soin de cela pour vous. L'utilisation de http pour d'autres demandes semble présenter certaines vulnérabilités. Maintenant, tout le monde avec un sniffer réseau peut intercepter votre trafic voler le jeton et usurper vos demandes. vous pouvez créer une protection pour l'empêcher: cryptage de jetons, utilisation de jetons, etc., mais vous allez recréer https. Pour en revenir à l'attaque https man in the middle - elle est basée sur la capacité de quelqu'un à s'intercaler entre votre serveur et votre client et à canaliser vos demandes via leur code. Tout est faisable, c'est-à-dire dans le cas où l'attaquant a accès au réseau physique. Le problème de cet attaquant est qu'il ne sera pas en mesure de vous donner un certificat numérique approprié - il n'a pas la clé privée que vous avez utilisée pour le signer. Lorsque https est accessible via un navigateur, le navigateur vous donne un avertissement mais peut encore vous laisser passer à la page.

Dans votre cas, c'est votre client qui communiquera avec le serveur. Et vous pouvez vous assurer que toutes les validations appropriées du certificat sont en place.Si vous faites cela, vous devriez être bien

Modifier

Détacher Yishai - oui certains frais généraux est impliqué, principalement CPU, mais si cette surcharge supplémentaire pousse votre serveur par dessus bord, vous avez de plus gros problèmes avec votre application

Answer 3

Première question, juste pour le dire: si vous êtes assez préoccupé par les mauvais accès client-imitateur, pourquoi ne pas mener toute la conversation sur HTTPS? Les performances minimales atteintes sont-elles suffisamment importantes pour cette application, ce qui ne justifie pas l'ajout de la sécurité? Deuxièmement, comment quelqu'un peut rejouer la demande de connexion? Si je ne me trompe pas, cela se passe sur HTTPS; Si la connexion est correctement configurée, HTTPS empêche les attaques de relecture à l'aide de nonces à usage unique (voir here).