probleme session php

jeanmouk · 24-12-2012 11:10:15

Bonjour,

Je suis ce qu'on peut appeler en débutant en php et je cherche à résoudre ce que ej considère comme une énigme...
J'ai créé un formulaire d'enregistrement qui remplit une BDD nommée ed_users
Suite à celà j'ai un formulaire d'identification qui vérifie si l'utilisateur fait bien partie de cette BDD ed_users
Enfin, j'ai créé une page 'blog' que j'aimerais rendre accessible qu'aux utilisateurs identifiés et là... c'est le drame ça ne marche pas c'est à dire que quand je veux accéder à la page 'blog' même sans avoir rentré mes identifiants, je ne suis pas rejeté... et je ne comprends pas pourquoi.

Voici mes codes :

page login.php

<?php

include('connection.php');

if(isset($_POST) && !empty($_POST['username']) && !empty($_POST['password'])) {

  extract($_POST);

  // on recupère le password de la table qui correspond au login du visiteur

  $sql = "SELECT password FROM ed_users WHERE username='".$username."'";

  $req = mysql_query($sql) or die('Erreur SQL !<br>'.$sql.'<br>'.mysql_error());

  $data = mysql_fetch_assoc($req);

  if($data['password'] != $password) {

    include('failure.html'); 

    exit;

  }

  else {

    session_start();

    $_SESSION['login'] = $username;

    include('sucess.html');

  }    

}

else {

  echo '<p>Vous avez oublié de remplir un champ.</p>';

   include('login.html');

   exit;

}

?>

Page de vérification de la session

<?

session_start();

if(!isset($_SESSION['login'])) {

  echo 'Vous n\'êtes pas autorise à acceder à cette zone';

  include('failure.html');

  exit;

}

?>

Et enfin la page que je veux rendre accessible aux utilisateurs identifiés

<?php

include('checksession.php');

?>

<!doctype html>

<html>

<head>

  <title>....

Merci d'avance pour votre aide

Jc · 05-01-2013 16:54:32

Bonjour,

Meilleurs voeux 2013.

if(isset($_POST) && !empty($_POST['username']) && !empty($_POST['password'])) {
extract($_POST);

Le problème avec ce bout de code c'est que vous ne vous assurez pas de l'existence de $_POST['password']) et donc de l'existence de $password qui dans un tel cas de figure serait égal à null. Pour peu qu'il en soit de même pour $username (même contexte) l'inégalité suivante

if($data['password'] != $password) {
include('failure.html');
exit;
}

n'est pas vérifiée et failure.html n'est pas lu, ce qui a pour conséquence de passer quand même en mode connecté même quand vous ne l'êtes pas.

C'est aussi simple que cela.

Dernière modification par Jc (05-01-2013 16:55:05)

nicolas · 09-01-2013 11:08:05

Et j'ajouterai, par parenthèses, que c'est une très mauvaise pratique que de ne pas crypter les mots de passe dans la base de données.

Jc · 18-01-2013 11:35:10

Je profite que Nicolas aborde le sujet pour dire que la première raison à cela - ne l'oublions pas - n'est pas pour une raison sécuritaire applicative mais pour que l'abonné sur le site concerné ait un mot de passe qui reste confidentiel (rappel : que lui seul connait), qui reste - ne l'oublions pas non plus - une obligation légale pour le propriétaire du site vis-à-vis de ses abonnés. Cela évite qu'un employé indélicat du côté administration site récupère un mot de passe et le réutilise par exemple pour se faire passer pour le client et faire ce que bon lui semble. D'ailleurs les mots de passe sont souvent réutilisés ailleurs (ne le faites pas) ce qui peut permettre bien d'autres choses à une personne mal intentionnée si le mot de passe est identique à celui d'une connexion bancaire par exemple.

N'oubliez pas non plus que cela n'est pas suffisant : pour garantir la confidentialité du mot de passe, seul une connexion SSL entre le serveur et le client peut véritablement le permettre (installation d'un certificat SSL du côté serveur). Or plus de la moitié des sites en France n'en possèdent pas. A une époque ou les problèmes d'usurpation d'identité sont monnaie courante (pour ne citer qu'un exemple parlant, dont tout le monde a entendu parler), les propriétaires de ces sites sont inconscients de ne pas mettre en place un tel certificat surtout qu'ils ont une responsabilité pénale vis-à-vis des informations qui leur sont confiées. C'est bien plus facile et moins salissant de récupérer les identifiants de connexion de qui on veut sur un site internet non sécurisé, que de fouiller un conteneur de poubelle dans la rue pour trouver les coordonnées d'une personne.

Je laisse à tous les lecteurs le soin de méditer tout cela sérieusement.

++

Dernière modification par Jc (21-01-2013 14:57:17)

mirindrasolo · 08-02-2013 08:53:05

Bonjour,
Pourriez-vous m'aider à trouver ce qui ne va pas dans mon code de verification du login. Ca sort toujours en erreur.

<?php
session_start();
$loginOK=false;
if(isset($_POST)&&(!empty($_POST['username']))&&(!empty($_POST['password']))){
extract($_POST);

try

  {

  $bdd = new PDO('...', '...', '...');

  }

  catch (Exception $e)

  {

  die('Erreur : ' . $e->getMessage());

  }

  $donnees = $bdd->query('SELECT * FROM members WHERE username = \''.$_POST['username'].'\'') or die(print_r($bdd->errorInfo()));

  if (mysql_num_rows($donnees) > 0) {

     $data = mysql_fetch_assoc($donnees);

    if(md5($_POST['password']) == $data['password']) {

      $loginOK = true;

    header('location:memberaccount.php');

    }

  }

}

if ($loginOK) {

  $_SESSION['username'] = $data['username'];

  $_SESSION['name'] = $data['name'];

  $_SESSION['email'] = $data['email'];

  $_SESSION['subscriptdate'] = $data['subscriptdate'];

}

else {

  echo 'Erreur !';

}

?>

Merci d'avance.

Pierrot · 08-02-2013 09:25:48

>>$bdd = new PDO('...', '...', '...');
....................
if (mysql_num_rows($donnees) > 0) {
$data = mysql_fetch_assoc($donnees);
mysql_num_rows et mysql_fetch_assoc ne sont pas des function PDO )
et c'est quoi ton erreur :?:

a++

Jc · 15-02-2013 04:06:19

Bonjour,

Oui outre le problème de librairie PDO/mysqli évoqué par pierrot,

if(md5($_POST['password']) == $data['password'])

si cette égalité est vérifié avec MySQL je te paye des figues, sauf si le md5 est généré côté PHP avant d'être stocké en BD, mais alors .... portabilité du code : zéro pointé.
Surtout quand faut migrer un site e commerce développé ainsi vers toute solution développée à minima normalement, du style CMS, et qu'il faut changer les mots de passe de 2500 clients car ils ne peuvent plus se connecter à leur compte, j'en connais qui ont déjà eu le problème...

Maljuna Kris · 15-02-2013 08:26:09

Bah alors, mon Jc, des insomnies, comme les vieux ?

nicolas · 15-02-2013 08:52:35

Jc a écrit :

Bonjour,
Oui outre le problème de librairie PDO/mysqli évoqué par pierrot,
if(md5($_POST['password']) == $data['password'])
si cette égalité est vérifié avec MySQL je te paye des figues, sauf si le md5 est généré côté PHP avant d'être stocké en BD, mais alors .... portabilité du code : zéro pointé.

Non ce n'est pas forcément stupide de ne pas faire dépendre le hachage des mots de passe par le moteur de base de données. Dans la base, quelle qu'elle soit, on stocke des chaînes de caractères. On hache le mot de passe avec PHP et on peut alors choisir l'algorithme que l'on veut, par exemple bcrypt que l'on ne retrouve pas dans tous les moteurs de base de données loin s'en faut !

Maljuna Kris · 15-02-2013 10:48:59

nicolas a écrit :

Non ce n'est pas forcément stupide de ne pas faire dépendre le hachage des mots de passe par le moteur de base de données. Dans la base, quelle qu'elle soit, on stocke des chaînes de caractères. On hache le mot de passe avec PHP et on peut alors choisir l'algorithme que l'on veut, par exemple bcrypt que l'on ne retrouve pas dans tous les moteurs de base de données loin s'en faut !

Où l'on retombe, en partie du moins, sur le vieux débat entre les SGBD épais et les SGBD maigres.
Personnellement j'opte, comme Jc, pour la portabilité au sein du SGBD, mais il est vrai que ça se discute.
D'autant qu'en termes de sécurité, l'encryptage en PHP permet de ne pas faire transiter les mots de passe en clair entre PHP et MySQL.
On me dira que le risque est bien plus grand avec HTTP entre le navigateur et le serveur à quoi je répondrai : certes.

nicolas · 15-02-2013 14:34:59

Maljuna Kris a écrit :

nicolas a écrit :
Non ce n'est pas forcément stupide de ne pas faire dépendre le hachage des mots de passe par le moteur de base de données. Dans la base, quelle qu'elle soit, on stocke des chaînes de caractères. On hache le mot de passe avec PHP et on peut alors choisir l'algorithme que l'on veut, par exemple bcrypt que l'on ne retrouve pas dans tous les moteurs de base de données loin s'en faut !
Où l'on retombe, en partie du moins, sur le vieux débat entre les SGBD épais et les SGBD maigres.
Personnellement j'opte, comme Jc, pour la portabilité au sein du SGBD, mais il est vrai que ça se discute.
D'autant qu'en termes de sécurité, l'encryptage en PHP permet de ne pas faire transiter les mots de passe en clair entre PHP et MySQL.
On me dira que le risque est bien plus grand avec HTTP entre le navigateur et le serveur à quoi je répondrai : certes.

Je ne cherche même pas à tomber dans ce débat. As-tu cliqué par curiosité sur le lien proposé (ou peut-être connais-tu déjà) ? L'idée de l'algorithme est mieux sécuriser les mots de passes hachés. D'une part, l'algorithme est volontairement lent en temps d'exécution pour empêcher toute découverte facile de mot de passe par attaque brute si la base de données est compromise par exemple. Pour une authentification de temps en temps cela ne devrait pas être pénalisant pour les visiteurs.

Maljuna Kris · 15-02-2013 15:35:23

Ouais, mais avec tout cela je crains, une fois encore, que le remède deviennent pire que le mal.
Je m'explique : on est loin des préoccupations de notre "clientèle", les débutants.
Il ne faudrait pas qu'à l'instar de ceux des médecins de Molière, nos patients meurent guéris. (oserai-je l'imparfait du subjonctif : "mourussent" ?)

Jc · 15-02-2013 15:38:24

Bonjour

maljuna kris a écrit :

Bah alors, mon Jc, des insomnies, comme les vieux

Ben faut dire que le Jc est plus proche de la soixantaine que de ses 20 ans vu que je viens d'attaquer la deuxième moitié de l'intervalle.. Déjà un signe avant coureur?

nicolas a écrit :

Non ce n'est pas forcément stupide de ne pas faire dépendre le hachage des mots de passe par le moteur de base de données. Dans la base, quelle qu'elle soit, on stocke des chaînes de caractères. On hache le mot de passe avec PHP et on peut alors choisir l'algorithme que l'on veut, par exemple bcrypt que l'on ne retrouve pas dans tous les moteurs de base de données loin s'en faut !

Comme l'a justement fait remarquer MK, je ne vais pas rentrer dans ce débat une fois de plus. Cependant je vais quand même rajouter ceci:
En ce qui me concerne, cette pratique de vouloir hacher un mot de passe au niveau PHP est une mauvaise pratique à plus d'un titre:

- Gros problèmes de portabilité du code - Injection SQL
a) Les serveurs tiers voient leur bibliothèques de cryptage évoluer avec le temps, et on a pas forcément de la portabilité entre les versions. Le cahier des charges au niveau base de données est différent pour ces raisons. Ainsi un MD5 PHP ne sortira pas un MD5 identique à celui d'une BD, notamment MySQL, et aujourd'hui SHA1 est le minimum syndical...
b) La comparaison au niveau base de donnée de type "password=SHA1('$password')" évite tout problème d'injection également ou de hack "in between".
c) Ceux qui font cela par ignorance pour compenser l'absence de certificat SSL (seule justification qui à le mérite qu'on s'y attarde), il faut qu'ils comprennent bien qu'une fois sur le serveur PHP, c'est déjà trop tard : il faudrait le faire au niveau javascript pour que cela ait un quelconque intérêt. Mais je m'y refuse personnellement à cause du b). (puis faudrait crypter en js et décrypter en php toutes les communications en manuel, qui reste dans tous les cas moins performant qu'un certificat...)
d) L'exemple de Jeanmouk est de plus mauvais car il fait pointer la condition where de sa requête sur le nom d'utilisateur.. or il faut faire pointer, et surtout dans un contexte d'identification certaine, les conditions d'une telle requête sur une clé unique ou clé composée unique.
e) MK est là pour me garder de mentir, je ne suis pas quelqu'un qui porte les CMS dans son cœur (avec une petite préférence pour prestashop qui sort un peu du lot), mais il faut bien reconnaître qu'ils n'ont pas ce défaut là à savoir de hacher les mdp au niveau PHP, et ce n'est pas par hasard non plus.

En résumé pour tous les lecteurs de ce forum, faites comme vous voulez, vous ne pourrez pas dire que vous n'avez pas été prévenus, mais si vous choisissez de hacher vos mots de passe en PHP, utilisez tout sauf MD5.

++

Dernière modification par Jc (15-02-2013 16:00:13)

Jc · 15-02-2013 15:49:06

Re,
@ nicolas: certes pour bcrypt mais bcrypt n'est pas non plus un modèle de stabilité et de portabilité contrairement à pgcrypto sous postgres qui en plus de cela lui est bien supérieur.

PHP|Débutant :: Forums

Advertisement

#1 24-12-2012 11:10:15

probleme session php

#2 05-01-2013 16:54:32

Re : probleme session php

#3 09-01-2013 11:08:05

Re : probleme session php

#4 18-01-2013 11:35:10

Re : probleme session php

#5 08-02-2013 08:53:05

Re : probleme session php

#6 08-02-2013 09:25:48

Re : probleme session php

#7 15-02-2013 04:06:19

Re : probleme session php

#8 15-02-2013 08:26:09

Re : probleme session php

#9 15-02-2013 08:52:35

Re : probleme session php

#10 15-02-2013 10:48:59

Re : probleme session php

#11 15-02-2013 14:34:59

Re : probleme session php

#12 15-02-2013 15:35:23

Re : probleme session php

#13 15-02-2013 15:38:24

Re : probleme session php

#14 15-02-2013 15:49:06

Re : probleme session php

Pied de page des forums