Discussion :

[digger]

bonjour

je dois migrer une application de php7.4 a php8.1 pour des raisons de sécurité en entreprise
mon application qui utilisait les sessions pour s'authentifier en php7 ne fonctionne plus en PHP8
on me dit que php8 est plus severe mais je tourne en rond

merci de votre aide

formulaire login

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<?php
// on teste si le visiteur a soumis le formulaire de connexion
if (isset($_POST['valider']) && $_POST['valider'] == 'Connection') {
if ((isset($_POST['usersadc']) && !empty($_POST['usersadc'])) && (isset($_POST['passwd']) && !empty($_POST['passwd']))) {
$passwd=(isset($_POST['passwd'])) ? addslashes($_POST['passwd']) : NULL;
$usersadc=(isset($_POST['usersadc'])) ? addslashes($_POST['usersadc']) : NULL;
$query="select * from users where usersadc='$usersadc' AND passwd='$passwd'";
$res=pg_query($conn,$query) or die('Erreur SQL !<br />'.$sql.'<br />'. pg_last_error($conn));
$data=pg_fetch_array($res);
$num=pg_num_rows($res);
if ($num == 1 ) {
session_start();
$_SESSION['usersadc']=$data['usersadc'];
$_SESSION['passwd']= $_POST['passwd'];
$_SESSION['status']= $data['status'];
header('Location: appli.php');
}
else {
$erreur="Compte non reconnu, loggin ou mot de passe incorrect";
}
}}
?>

page ou il y a verifif des sessions les sessions ne fonctionnent pas j'ai une erreur Error undefined key

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
<?php
session_start();
if (!$_SESSION["usersadc"] && (!$_SESSION["status"])) {
header ("location: ./index.php");
die();
}
include "php/init.php";
include "inc/header.php";
?>

merci de votre aide

[cavo789]

Bonjour

Il faudrait indenter ton code pour que sa lecture soit plus simple.

Plusieurs trucs m'interpellent dans ton code comme le fait que tu stockes le mot de passe dans une variable de session (oups !) et que ton code semble quand même faire un query si et le login et le mot de passe est nul. Pour peu que tu ais un enregistrement dans ta table avec les colonnes login et password vides, ton utilisateur est connecté (oups).

Je suis actuellement en déplacement aussi compliqué de lire ton code depuis un smartphone, je n'ai pas vu d'erreur flagrante de code excepté ce que je mentionne ci-dessus et qui me font penser que ton code est trop basique et devrait être réécrit.

L'authentification est quelque chose de trop sérieux que pour avoir un code bancal.

(note : typo dans ton message d'erreur login ne prends qu'un seul "g")

[mathieu]

peut-être qu'il s'agit aussi de la configuration du serveur qui a changé entre les 2.
mettez ce code dans un fichier seul et rafraichissez la page plusieurs fois pour voir si le compteur change :

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
<?php
session_start();
 
if (!isset($_SESSION["test"])) {
	$_SESSION["test"] = 0;
}
 
echo ++$_SESSION["test"];

[binarygirl]

page ou il y a verifif des sessions les sessions ne fonctionnent pas j'ai une erreur Error undefined key

A quel endroit ? Normalement le message d'erreur devrait au moins cracher le numéro de la ligne. Vous devriez poster les messages d'erreurs complets.

On voit que ce code est très ancien: usage abusif de addslashes, stockage du mot de passe en clair mais pire encore vulnérabilité aux injections SQL ! C'est le genre de code qu'on voyait malheureusement il y a 20 ans (et qui était déjà vulnérable).
J'espère que c'est juste un intranet avec des utilisateurs bien élevés et que ce code n'est pas exposé publiquement car c'est un jeu d'enfant de pomper votre base de données avec des failles aussi béantes...

Ce code ne doit pas être corrigé, il doit être refait. En cas d'incident (hacking), et sans parler des conséquences directes que ça entraîne, il peut y avoir un audit de la CNIL et des lourdes amendes à la clé pour négligence, on voit ça régulièrement. Ici un exemple récent qui implique EDF, avec certains points techniques qui vous intéressent comme le hashing de mots de passe. Dans le cas dont il est question, il était insuffisant mais il existait quand même, ce qui n'est pas le cas chez vous.
Je vous conseille d'en parler avec vos chefs et de leur expliquer qu'une refonte du code est nécessaire, pour être conforme aux minimum des bonnes pratiques actuelles. Vous engagez votre responsabilité professionnelle en laissant ce genre de code en production.
Et passer de PHP 7 à 8 ne résoudra pas ce problème de sécurité.

Ici, il est même possible que addslashes modifie le mot de passe, de sorte qu'il ne peut être comparé à celui enregistré dans la DB. Ca devrait être facile à vérifier, mettez des print pour afficher les valeurs des variables.
Mais effectivement, ça peut être la nouvelle configuration qui fait ressortir ce problème.

Le problème, c'est que même si vous corrigez cette routine, il y a probablement des injections SQL dans les autres pages, et ces pages sont donc tout aussi dangereuses.

[ddaweb]

Ce code ne doit pas être corrigé, il doit être refait. En cas d'incident (hacking), et sans parler des conséquences directes que ça entraîne, il peut y avoir un audit de la CNIL et des lourdes amendes à la clé pour négligence

Aurais-tu un code assez sécurisé ou ce que je fais ci-dessous est suffisant ?

Vu que cela a un lien direct avec le post original, je me permet d'intervenir et demander également conseil.
Pour ma part, je refais notre interface de gestion de l'association et je compte la mettre avec une très bonne sécurité vu que cette page est sur internet (même si elle n'est pas référencée pour les bots).

Je travaille sur 3 pages :
1. La page du formulaire
2. Le traitement du login (page de passage avec redirections suivant les cas)
3. La page affichée

Côté du mot de passe, il est encrypté et un champs varchar(45) dans la DB :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$sha1 = sha1($grain.$pw.$sel);

Il y a du grain de sel, c'est historique et avant le SH1 que j'ai implémenté avec PHP 7, mon ancien hash était déprécié (md5 je crois)

La lecture du login et pw :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$pw = mysqli_real_escape_string($conn, htmlspecialchars($_POST['pw']));

idem pour le login, je vérifie si les POST ne sont pas vide

Dans la gestion du login:
1. je mets qu'il y a une erreur de login par défaut en début de page : $pw_passe='nok';
2. je lis ma DB pour la vérification du login, qui est sur 2 tables avec un INNER JOIN et si une concordance est trouvée, je redirige vers la page finale et $pw_passe='ok'; est mit en session, sinon retour au login.

Pour les pages :
1. je lis la session du pw_passe est présente et si oui,'ok' et si n'est pas correct -> redirection vers la page du login : en cas d'utilisation de l'url des pages sans login (idem si session expirée).
2. il y a également des droits sur les menus suivant qui se connecte (tout le monde n'a pas les mêmes droits suivant sa fonction au sein de l'association : ex. le secrétariat n'a pas accès aux pages comptables).

Aurait-il des chose à modifier ?

Si cette méthodologie est correct, @ Digger pourrait s'en inspirer

[binarygirl]

La lecture du login et pw :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$pw = mysqli_real_escape_string($conn, htmlspecialchars($_POST['pw']));

idem pour le login, je vérifie si les POST ne sont pas vide

Déjà, mysqli_real_escape_string ça ne sent pas bon, ça sent la naphtaline
J'espère au moins que vous bien lu la doc à ce sujet pour comprendre les pièges et limitations de cette méthode.
Si vous utilisez des requêtes paramétrées ou un ORM, vous n'avez pas besoin de ce bricolage. Ou pourquoi pas en PDO.
D'ailleurs pourquoi altérer le mot de passe avec htmlspecialchars ? Vous ne cherchez pas à l'afficher, mais à le hasher pour ensuite stocker le condensat (comme on dit en hexagon). A la limite vous pouvez faire un regex pour baliser les caractères autorisés, encore que... c'est un sujet de discussion en soi. Les règles de mots de passe autorités varient d'un site à l'autre et sont souvent peu sensées.
Mais ne transformez pas en silence le mot de passe qui a été fourni par l'utilisateur. Car un mot de passe complexe va être mal traité, résultat: bug. L'utilisateur ne peut pas se logger.

Il existe des fonctions en PHP comme password_hash, donc vous ne devriez même faire ces manips de hashing. Mais rien ne vous empêche d'utiliser une lib éprouvée pour cela.
Au hasard: PBKDF2

Si vous utilisez un framework, il est possible qu'il existe déjà des outils pour cela également.

Un sujet intéressant mais en anglais: Password Storage Cheat Sheet

[ddaweb]

Déjà, mysqli_real_escape_string ça ne sent pas bon, ça sent la naphtaline

En effet c'est le code de pas mal d'années, juste mit à jour pour mysqli au lieu de mysql
Il ne sert qu'à éviter les injections de code via le formulaire ... mais je vais relire à ce sujet et la bonne pratique.

Pour ce qui est du PW il est déjà dans la DB à ce moment là car quand on crée un nouvel utilisateur, cela se fait via un autre processus et un MDP provisoire est généré qui doit être changé avant de pouvoir se connecter (le même processus quand je force le changement de code après un certain temps ... ils n'ont pas le choix et ne peuvent pas remettre l'ancien ... il y a moyen de contourner, mais chuuuut pas leur dire comment).
Il y a des conditions : longueur, lettre et chiffre + certains caractères spéciaux qui ne sont pas utilisés dans le codage (pour éviter des soucis)

Concernant le PDO ... non trop tard pour moi d'apprendre, j'arrive à +/- bien le lire, mais l'écrire
Quand j'ai commencé, je ne connaissais rien à PHP et encore moins MySQL ... c'est par le Site du Zéro (un peu de nostalgie) que j'ai appris les bases, le reste, avec le temps et parfois beaucoup de recherche et lecture

EDIT : il n'y a que quelques utilisateurs, ceux qui ont une fonction au sein de notre association