Dailymotion rattrape Arte :bounce:
Admirez le travail :o [:shy]
Quelqu’un qui ferait du PHP pourrait me dire ou yaurait un probleme dans cette methode de sécurité :
img9.imageshack.us…
Merci
Pas tout saisi, mais je dirais que la faille c’est sur un réseau d’entreprise ? (plusieurs PC ont au final la même IP).
Bah en fait je considère que le cookie contenant le PHPSESSID n’est pas fiable (un vol de cookie avec wireshark et hop). Donc je proposais de faire une sécurité un peu plus élevée.
-
Premier passage, identifications via formulaires, identifiants bons :
-> Récupération des identifiants, et de l’adresse ip interne du client, via un applet java.
-> Création d’un identifiant unique (comme celui des sessions habituelles de PHP).
-> Avec un cryptage simple (a définir, hein, mais vraiment tres simple), on crypte l’identifiant unique avec l’IP récupérée
-> On inscrit dans une table du SGDB (comportant deux champs, disons : idcrypte et variable) : la chaine cryptée obtenue, et dans un variable, pour faire simple, un code PHP qui devra etre eval(). Disons $s[“pw”] = “a”;$s[“lo”] = “b”;$s[“IdUniqueNonCrypte”] = “1234”;
-> On crée un cookie pour l’utilisateur qui contiendra uniquement l’ID crypté. -
Deuxième passage, rien rentré, juste check du cookie :
-> On récupère l’ip interne, on récupère la valeur du cookie.
-> En utilisant l’inverse du cryptage, on tombe sur l’ID non crypté (si le cookie est bon, et que l’ip interne n’a pas changé entre deux pages).
-> On va dans la SGDB, avec “… WHERE idcrypte = $valeurDuCookie;”
-> On fait l’eval;
-> On compare l’ID de la SGBD avec l’ID décrypté
==> Si ca ne correspond pas : Soit l’ip n’est pas la meme (donc vol de session detécté, ou ip changé entre deux pages), soit bug dans la valeur du cookie.
==> Si ca correspond, on log.
Cette technique est bouffeuse de ressource, elle utilise eval et tout, mais elle est quand meme bien plus sécurisée qu’un simple cookie contenant la PHPSESSID, puisque on vérifie l’ip interne.
Je demandais donc votre avis 
Le cryptage pourrait etre IP Interne (sans les points) * ID généré = ID crypté, par exemple, vraiment un truc simple.
pour ton cryptage d’ID, te prends pas la tête et fait un hash 
… c’est beaucoup plus efficace en terme de timing/mémoire, et tu conserves la sécurité durant la query SQL (puisque tu compares les valeurs hashés, et que tu n’as pas besoin de “décrypter” la valeur) … par exemple du sha1 qui est supporté tant par PHP que par MySQL en natif :oui:
$hash = hash('sha1', 'mon mot de passe');
$sql = "SELECT ......FROM ... WHERE SHA1(password) = '$hash'";
comme ça, si quelqu’un écoute ton serveur SQL, il verra passer une jolie query de la forme :
SELECT …FROM … WHERE SHA1(password) = ‘d2231dsf543e2zr001z2er0dsf01sdf45604sd3f’
ce qui ne l’aideras pas des masses pour trouver le mot de passe :paf:
et sinon là je comprend pas l’intérêt du champ “variable” dans la DB (ni du code eval) :neutre:
pour rajouter un peu de difficulté, tu peux aussi rajouter le HTTP_USER_AGENT (qui est censé être invariant durant une session de surf)
enfin, fais bien tout ça “over SSL”, sinon ça serviras pas à grand chose (car là de base, je ne vois pas en quoi un vol du cookie empêcherais un hack de ton appli)
perso, ce sont les checks que je fais sur mes applis web, avec un session_regenerate_id() à intervalle aléatoire pour éviter les “sessions fixs exploits” :oui: …
Edité le 07/12/2010 à 23:19
Ouais, puis le over ssl, c’est pas non plus ultra secure suffit de coller un proxy entre le client et le serveur, et paf Donc SSL + Certificats client mais sans l’échanges de clef (connue à l’avance, etc).
+1 'vec “man with no name” :o
Je crois vous avez pas tout saisi. Que le mot de passe soit en sha1 ou en rsa2048, ca ne change rien, il suffit de voler la session pour tout casser. Moi je cherchais une session sécurisée, ou meme en volant le cookie de la session du voisin en lui piratant son wifi, on ne puisse pas se connecter.
Pour ça, SSL + certificats clients (comme pour le site des impôts, ancienne version) :oui:
Sinon, expliques-nous en quoi tu pensais que ta solution n’était pas sujet à ce problème de vol de cookie, parce que là je vois pas :neutre: …
Bah dans ma solution, on vérifie l’ip client ;). Et pour changer une ip client, sachant que les confilts sont impossibles, je sais pas comment faire 
Bah dans la mienne aussi :o
Et dans la mienne en prime, on vérifie aussi le User Agent du navigateur du client (comme ça sur le même poste, il faut utiliser le même navigateur, sinon fuck ) …
Bon, j'ai bien fait de demander si on pouvait avoir les nouveaux calendrier Marc Dorcel au taff (me suis occupé de coder l'injecteur automatique) : "pour les calendriers, je suis contente de pouvoir vous dire que vous n'allez pas tarder à recevoir l'édition 2011 en plusieurs exemplaires !" :bounce: Edité le 08/12/2010 à 17:20
Si tu arrive a récupérer l’ip interne avec du PHP bravo :paf:
Mais l’id du HTTP_USER_AGENT n’est pas mauvaise
Ca évite de faire tout un systeme de gestion puisque tu peux le stocker facilement dans la BDD
Tiens buen ca
Problème avec le HTTP_USER_AGENT, il est envoyé dans n’importe quel header. Donc récupérable avec WireShark ou autre sniffeur
Certificat client envoyé par email surtout, et pas proposé via https. Cela limite les risques.
IP externe + UserAgent est suffisant (dans la plupart des cas) pour identifier un poste unique :jap: … Après, tu peux toujours rajouter un grain de sel basé sur un timestamp à la microseconde :oui: …
Mais bon, tant que tu te bases sur des données publics, tu pourras toujours tes les faire compromettre :oui: …
+1 :neutre: …
Pour certains systèmes bancaires, j’ai même eu droit au certificat envoyé en deux morceaux : un par mail, un par la poste sur CD :paf: …
Mais le problème, c’est que pour choper la session, faut etre dans le meme réseau, donc meme ip externe. Apres il suffit d’avoir le meme navigateur, et c’est pas ce qu’il y a de plus compliqué à trouver.
Et le timestamp, ce serait le timestamp de quoi ? De l’heure de la derniere visite ?
Sinon tu récupères dans le HTTP header la valeur du HTTP_FIREWALL_OPENOFFICE, et s’il est pas installé, tu refuses la connexion. Comme ça tu garanties que la ligne est sécurisée du point de vue client.
Par exemple … comme ça, ça fait varier le hash à chaque connection :oui: …
Mais ça impose de stocker ce “grain de sel” en base :neutre: …
Tu vas avoir des problèmes
Soit, mais je ne comprend pas comment vérifier apres si c’est bien un utilisateur, et pas le voisin qui l’a hacké. En quoi le timestamp prouve-t-il quelquechose ? Pourrait on récupérer le timestamp de la page d’avant ou un truc du même genre ?
Et comment tu fais lorsqu’il ouvre pour la première fois ta page ?