Vous n'êtes pas identifié(e).
Pages :: 1
Bonjour à tous,
Avant de faire mes études en informatique, j'ai fait mes premiers pas en php grâce à votre site. C'est un peu vous qui m'avez donné le goût de l'informatique
J'aimerai bien apporter un peu mon aide aujourd'hui et rendre ce que vous m'avez apporté.
J'ai repéré un problème de sécurité avec le tutoriel sur les sessions.
Dans le code proposé pour la page verifLogin.php, on lit ce bout de code :
Il faudrait ajouter une destruction de la session courante avant d'affecter des valeurs à la variable de session. cela empêcherait un vol de session.
J'explique une attaque assez simple sur ce type de code :
- Le pirate va sur la page d'authentification et rentre de mauvaises informations, il va récupérer dans son navigateur un cookie de session PHPSSID.
- Le pirate, envoi ce cookie sur une machine victime (manuellement, via réseaux sociaux ou encore virus...)
- Une fois que la victime se connecte, le pirate sera automatiquement connecté parce que la variable de session de la victime n'aura pas changée
Qu'en pensez vous ?
Hors ligne
Bonjour,
Bien que notre MK national est partisan à juste titre d'apprendre les bonnes méthodes dès le départ aux autres, et que ta remarque soit pertinente, je pense que l'idée du tutoriel initialement était de donner les principes et un exemple. Peut-être que de mettre à jour les tutos serait une bonne chose, mais faudrait alors aussi que tout soit fait en PDO, etc... puis viens se greffer la-dessus la relativité du minimum suffisant en terme de sécurité. Bref pas évident tout cela...
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne
Salut,
Ecoute je suis pas trop d'accord, les problèmes de sécurités sont actuellement les soucis des plus grands sites internet.
Peut être que quelqu'un apprenant les bases de php, finira par produire un excellent site avec l'aide de phpdebutant. Je ne pense pas que l'on puisse laisser un tutoriel dans l'état car c'est dangereux.
Dans les phases de développement d'un site, il faut penser sécurité dès le début sinon c'est foutu. Pour le cas actuel, il suffit juste de rajouter une ligne de code, c'est un peu comme si vous faisiez un tutoriel sur les requêtes SQL sans se protéger des injections....
Hors ligne
plus besoin de se protéger des injections
a++
Hors ligne
Pierrot à raison, et si tu veux rentrer dans les détails, pas de problème.
Normalement,
1) Si toutes les principales bonnes pratiques de développement sont appliquées, pas de problème de sécurité ou cas isolés très spécifiques à traiter.
2) Si ces mêmes pratiques sont appliquées à la gestion des connexions et des sessions, pas de soucis que tu viens d'évoquer qui se profile à l'horizon.
Maintenant à partir de là, comment fais-tu, ou comment peux-tu faire pour vérifier la bonne implémentation et gestion des sessions en 5 lignes de code? C'est purement impossible. La seule chose qu'il soit possible de vérifier ici c'est que le mot de passe en clair de la connexion ne soit pas passée en session. c'est tout.
3) Tout ceci ayant été dit, je peux affirmer qu'une très bonne gestion d'existence de session (solide) ne se limite pas à un unset des variables + session_destroy au sein de ces 5 lignes de codes, mais est bien plus complexe que cela, car cela doit être intégré au niveau des algos de gestion de connexion et c'est au niveau de cet ensemble que la solidité du code doit être apréhendé pour en juger la solidité avec pertinence.
4) Moralité, la seule chose efficace pour aider et accompagner dans le développement de tout cela - dans un site comme PHP débutant - c'est d'en parler et de dire "attention à ceci, attention à cela, pour toutes ces x raisons. Ensuite c'est aux développeurs d'assumer leurs responsabilités dans leurs choix de développement
++
PS: Je pense qu'actuellement le grand problème des grands sites internets c'est de trouver des développeurs qui fassent fonctionner leur site correctement. Y a pas plus longtemps qu'hier, j'ai voulu me connecter sur le site de collissimo, erreurs dans les gestions de session justement, et impossible d'utiliser l'espace client.. et j'ai de quoi en raconter une tous les jours différente chaque jour de l'année (paiements impossibles, etc...), à tel point que ca fait peur sur les compétences des prestas au niveau national, à moins que les grandes sociétés françaises se soient mis à faire travailler des gens incompétents au rabais...:rolleyes:
Dans tous les cas, bonjour l'image de marque!
Dernière modification par Jc (16-07-2011 20:44:39)
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne
Connais-tu par exemple ce problème de sécurité ?:
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne
Salut,
oui je connais la RFC 5746 mais pas ce CVE.
Mais nous parlons ici de deux problèmes différents. La RFC et le CVE en question parle de l'implémentation et de la définition d'un protocole et d'une version de serveur.
Nous sommes a deux couches différentes car le développeur peut faire le meilleur code du monde, si sont serveur comporte une faille cela ne servira à rien....
Là je soumettais juste une idée, je ne conçoit pas qu'une variable de session soit la même avant et après connexion et je pense vraiment être dans le vrai.
C'est juste un problème logique qui révèle de bonne implémentation et le tutoriel des sessions de phpdebutant comporte pour moi une réelle faille de sécurité, plus grave que de mettre le password dans un cookie.....
Concernant ton Ps : 100% d'accord
Dernière modification par guillaumeD (17-07-2011 17:18:47)
Hors ligne
Bonjour
Là je soumettais juste une idée, je ne conçoit pas qu'une variable de session soit la même avant et après connexion et je pense vraiment être dans le vrai.
J'avoue que tu es dans le vrai, c'est incontestablement un plus d'avoir en quelque sorte une "session publique" et une "session privée" même si en l'occurence la "session privée" est ici accessible - dans une certaine mesure - en lecture au public. De plus au niveau algo, rien à redire.
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne
Pages :: 1