Salut.
Je voudrais faire un système de session sécurisé pour utiliser en http serveur<->clients.
Donc côté serveur, par défaut chaque visiteur n'ayant pas de cookie dans le http reçu est vu comme visiteur.
S'il veut s'identifier et qu'il fait une bonne combinaison user-password correspondant:
1- je crée un nombre unique et j'envoie au client par http la création d'une cookie ayant comme valeur le nombre unique
2- je crée dans le serveur une session_id chiffré en regroupant:
- le nombre unique (qui est crée pour le cookie)
- ip client
- port client
Quand quelqu'un visite:
S'il m'envoi une cookie, je vérifie le numéro cookie + son ip + son port et je fais un check de session si ça existe et correspond.
Si oui, c'est bien notre utilisateur authentifié.
Si ça correspond pas, c'est que soit la session est expiré soit c'est du vole de cookie l'ip et le port client ne correspond pas.
En gros j'ai penser à quelque chose comme ça.
Est-ce fiable ? y a t il d'autre chose à vérifié comme le navigateur ? le système ? je sais pas comment vérifie les applications connu.
# Protéger contre quoi ?
Posté par Kerro . Évalué à 1.
Ta fiabilité sera de presque 0 % car les requêtes http/https ne viennent pas obligatoirement de ports fixes.
Passe tes pages en http, et on commencera à parler sérieusement de sécurité.
[^] # Re: Protéger contre quoi ?
Posté par Anonyme . Évalué à 1. Dernière modification le 24 juin 2018 à 20:42.
Si le client change de port la vérification de port tombe à l'eau.
Quelles sont les bonnes méthodes utiliser ?
Pour ta dernière phrase je comprend pas où tu veux en arriver.
[^] # Re: Protéger contre quoi ?
Posté par NicolasP . Évalué à 2.
Ça arrivera dès qu'un navigateur voudra lancer plusieurs connexions simultanées.
Je suppose qu'il voulait dire HTTPS et pas HTTP. En HTTP, tu n'arriveras pas à faire quelque chose de sécurisé dans le cas général. Même si la technique de vérification du port était applicable, tu fais circuler les login/mdp en clair sur le réseau. Il n'y a aucun intérêt de protéger la session, si tes login/mots de passe ne le sont pas. Qu'est-ce qui t'empêche de mettre en place du HTTPS ?
[^] # Re: Protéger contre quoi ?
Posté par Anonyme . Évalué à 1.
Actuellement, j'apprend/j'applique des trucs basique du http dans mes tests pour un projet en tête.
Je n'ai pas encore passer au https, mais je devrais surement passer.
# vol de session
Posté par jemore . Évalué à 2.
Si tu veux une session sécurisée, il faut au minimum utiliser le HTTPS. Sinon, quelqu'un peut te voler la valeur du cookie, et éventuellement (s'il est motivé), se forger une adresse IP identique à celle de l'internaute.
Tu ne peux pas te baser sur l'adresse IP du client + le port, car si des internautes utilisent un proxy (en entreprise par ex) ou un telephone mobile, l'adresse IP et le port risquent de changer plus ou moins aléatoirement.
Par contre, ce qui changera mois, c'est le user agent (l'identifiant du navigateur). Tu peux mettre dans ton cookie un hash du user-agent + un salt coté serveur (+l'adresse IP en fonction de l'usage qui est fait de ton site).
Mais dans cas, si l'attaquant connait le user agent et le salt, il peut reconstituer le hash.
On trouve quelques astuces interessantes sur StackOverflow : https://stackoverflow.com/questions/17413480/session-spoofing-php
[^] # Re: vol de session
Posté par Anonyme . Évalué à 1. Dernière modification le 25 juin 2018 à 00:24.
+1 https.
Pour le port je comprend que les navigateurs récent avec leurs course à la sécurité qui pourrait changer de port.
L'adresse ip ça reste quand même le plus unique au client il me semble, mais comment différencier s'ils sont 2 à la même adresse (habitation) à la même version distribution à la même version navigateur.
Quand le premier se connecte, n'ayant pas de cookie, il se fait avoir une nouvelle cookie.
Le deuxième n'ayant pas de cookie, il se fait avoir une nouvelle cookie aussi.
Du coup le serveur n'a pas besoin de différencier, les 2 ont une cookie valable et séparé.
Si le deuxième copie celui du premier et l'envoi au serveur, j'ai pas de solution.
C'est un peu pour cela que j'ai ouvert le sujet, je sais pas quelles sont les problèmes auquel je dois faire attention.
[^] # Re: vol de session
Posté par jemore . Évalué à 2.
si tu detecte qu'un même utilisateur est logué plusieurs fois, tu peux afficher un warning (comme le fait GMail) ou carrément déloguer la session la plus ancienne (comme le fait linuxfr).
[^] # Re: vol de session
Posté par Anonyme . Évalué à 1.
Effectivement c'est à prendre en compte.
# Refaire ce qui existe déjà?
Posté par FantastIX . Évalué à 4. Dernière modification le 25 juin 2018 à 14:27.
D'après ce que je comprends, ce que tu essaies de faire est déjà mis en œuvre dans de gestion des sessions de PHP, par exemple — puisque tu ne donnes pas d'indication sur le langage, j'en profite pour mentionner celui-ci. Cette gestion des sessions PHP existe et est maintenue continuellement depuis très longtemps; le code est utilisé sur une masse énorme de serveurs sur l'internet — ceci pour dire qu'en toute logique tu peux faire confiance à ceux qui l'ont écrit, pour y avoir réfléchi longuement et pour continuer de le faire. Et comme d'autres l'ont dit, gérer la sécurité des sessions n'a pas de sens en dehors de HTTPS.
[^] # Re: Refaire ce qui existe déjà?
Posté par Anonyme . Évalué à 1.
Je connais les sessions sous php.
J'utilises c++.
[^] # Re: Refaire ce qui existe déjà?
Posté par FantastIX . Évalué à 2. Dernière modification le 26 juin 2018 à 15:21.
C'est délicat. Refaire le tout en partant de zéro ou pas loin, que ce soit en C/C++ ou quelqu'autre langage que ce soit, t'expose à des erreurs qui ont déjà été commises et réparées. Y a-t-il une raison de ne pas te servir d'un moteur existant?
On pourrait évoquer l'inconvénient des bugs: si le moteur est buggé, ton appli aussi est vulnérable. Par contre les avantages sont que:
1) la correction du moteur corrige aussi la vulnérabilité de ton appli,
2) la correction viendra probablement plus vite de la communauté que de tes propres ressources.
Ce n'est que du pragmatisme, je ne connais pas ta façon de programmer. C'est juste que la tâche est vraiment très délicate, en ne considérant déjà rien que la sécurité.
[^] # Re: Refaire ce qui existe déjà?
Posté par Anonyme . Évalué à 2.
Il y a déjà nginx qui fait le boulot pour la connexion serveur-client.
Moi je voulais étudier le fonctionnement, mais je trouves pas d'info.
# HTTPS ou DH
Posté par Moonz . Évalué à 2. Dernière modification le 25 juin 2018 à 14:55.
L’attaquant peut très bien avoir la même adresse IP qu’un client légitime. Un client légitime peut très bien changer d’adresse IP d’une page à l’autre (smartphone: je passe du Wifi à la 4G parce que je sors de chez moi par exemple).
La solution triviale et de bon sens à ton problème s’appelle HTTPS.
Si pour une raison étrange tu ne peux vraiment pas faire de HTTPS, tu n’as plus qu’à faire du DH à la main pour dériver un secret partagé et l’utiliser comme MAC pour authentifier ton cookie d’identifiant de session. Voir https://nacl.cr.yp.to/scalarmult.html et https://github.com/tonyg/js-nacl.
[^] # Re: HTTPS ou DH
Posté par Anonyme . Évalué à 1. Dernière modification le 25 juin 2018 à 16:38.
Ton expérience 4g m'intéresse.
Quand tu utilises le 4g est que ta parcouru une longue distance ou après un certain temps, ton ip change ? si oui, ton utilisateur (que tu t'étais connecté) reste connecté sur les sites ou elles te déconnectent ou te reconnaissent comme simple visiteur ?
J'insiste que je désire pas rester sur du http, j'essaye d'étudier le http et faire des trucs potable.
En réel pour un projet en production évidement je choisirais d'utiliser le https.
Pour le moment, je comptais:
1- bien distinguer le client ex. s'ils sont plusieurs en local et bien gérer s'il utilise 2 navigateurs différents, etc
2- utiliser l'ip comme protection, c'est pas une protection absolu mais un attaquant hors du réseaux client à forcement un ip différent, donc ça réduit considérablement l'attaque. Et si je pouvais arriver à vraiment distinguer les utilisateurs du même réseaux, même ayant l'ip identique je pourrais différencier et bloquer en cas d'attaque. C'est un peu trop voulu pour du http simple mais bon si ça peut marcher autant sécuriser du mieux.
Et je répètes: pour un projet en production évidement je choisirais d'utiliser le https.
[^] # Re: HTTPS ou DH
Posté par Moonz . Évalué à 2.
Aucune idée, je parlais d’un switch Wifi/4G.
Dans l’extrême majorité des cas, oui, je reste connecté.
Tu peux. Pour mitiger un attaquant passif (écoute) tu as juste à générer une paire de clé côté client en Javascript et signer (cookie + nonce). Pour un attaquant actif (MitM), Diffie-Hellman et signature symétrique de (cookie + nonce).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.