[jerem3000]

Bonjour,

Je fait quelque test d'injection sql en local et je me suis donc mit a tester la sécurité d'un site que j'avais crée il y a quelques années.

le système d'authentification se fait via un formulaire POST et il effectue cette requête dans la base.

SELECT * from user where code = '". $_POST['login] . "' and mdp = '" . $_POST['pass'] ."'

les passwords sont en clair dans la base et les variable reçu sont traiter de cette façon

mysql_real_escape_string(htmlspecialchars($_POST['login']));

Aprés pas mal de recherche je n'est rien trouver pour faire une injection SQL

j'aimerais donc avoir l'avis de personnes plus expérimenter que moi dans ce domaine sur mon système d'authentification.

Merci d'avance

Jerem3000

[the lsd]

mais euhhh, il y a un gros souci là ! Si j'ai bien compris, ton code, c'est ca ?

Code:

mysql_real_escape_string(htmlspecialchars($_POST['login']));
mysql_query(SELECT * from user where code = '". $_POST['login] . "' and mdp = '" . $_POST['pass'] ."');

Dans ce cas, login n'est pas protégée. Il faut faire ca :

Code:

$login = mysql_real_escape_string(htmlspecialchars($_POST['login']));
mysql_query(SELECT * from user where code = '". $login. "' and mdp = '" . $_POST['pass'] ."');

et pareil pour le pass, si tu continue à les stocker en clair. Le mieux étant de faire ca :

Code:

$login = mysql_real_escape_string(htmlspecialchars($_POST['login']));
$pass = sha1(sha1($_POST['pass']));
mysql_query(SELECT * from user where code = '". $login. "' and mdp = '" . $pass ."');

(pas besoin de mysql_real_escape_string ou d'htmlspecialchar, puisque ta variable est hashée et ne peut pas contenir de caractères spéciaux après le hashage).

Enjoy

The lsd

[jerem3000]

Code:

$login = mysql_real_escape_string(htmlspecialchars($_POST['login']));

C'est bien sa que j'ai fait, je me suis tromper en recopiant 

effectivement je devrait hashée le pass mais ce n'est pas sa que j'aimerais savoir.

je veut juste savoir si il est possible de outre-passer mysql_real_escape_string et htmlspecialchar .

et si c'est possible comprendre comment cela marche.

[_o_]

Code:

$pass = sha1(sha1($_POST['pass']));

Est-ce qu'il y a une bonne raison pour hacher le hachage ? C'est une vraie question : en l'occurrence, je ne vois pas de problème, mais souvent, c'est une mauvaise idée de combiner les algo de chiffrage, on peut se retrouver au final avec quelque chose de plus faible que l'un ou l'autre des chiffrages utilisés séparément.

[ymvunjq]

Est-ce qu'il y a une bonne raison pour hacher le hachage ?

Une raison... ca dépend...

Ici on pourrait toujours dire que ca éviterait une attaque par table précalculée sur des mots de passe relativement triviaux. Une seed reste néanmoins bien plus adaptée pour faire cela.

Une autre raison (mais pas ici) est de rendre l'opération volontairement couteuse en temps. C'est le cas par exemple pour le 4 way handshake en WPA/WPA2 où la clef est dérivée 4096 fois par une fonction HMAC-SHA1. Le brute force devient de suite beaucoup plus difficile à réaliser.

ymvunjq

[Ge0]

Est-ce qu'il y a une bonne raison pour hacher le hachage ?

Probablement : http://forge.mysql.com/wiki/MySQL_Internals_ClientServer_Protocol

4.1 and later

remember that mysql.user.Password stores SHA1(SHA1(password))

Pourtant, ça m'étonne car j'arrive pas à "retomber sur mes pattes" en faisant un double sha1 de mon password. Y'a-t-il une histoire de "salt" ? J'en sais rien. Mais bon, ils sont explicites.

Sinon, pour rester dans le sujet, on peut utiliser PDO et les requêtes préparées pour éviter de se faire "bypasser". ( _o_, cache tes yeux, c'est du PHP :p).

<?php
$bdd = new PDO('mysql:host=localhost;dbname=foo','user','pwd');

$query = $bdd->prepare('SELECT foo FROM bar WHERE field = ?'); // les '?' correspondent à tes variables contenant, elles-mêmes, une valeur lambda
$query->execute( array( htmlentities($_GET['variable'], ENT_QUOTES) ) ); // htmlentities() suffit
// etc...
?>

Après, je me demande s'il ne faut quand même pas utiliser intval() ou le cast (int) pour les valeurs entières. A vérifier.

[FiRe_StoRM]

Jusqu'a présent personellement je n'ai trouvé aucun moyen de bypasser ce genre de protection mais encore une fois ça dépend de beaucoup de chose.

Sur un formulaire de connexion, perso je ne pense pas être capable de bypasser quoi que se soit, par contre si ta requête est plutôt:

Code:

$id = mysql_real_escape_string(htmlspecialchars($_GET['membre']));
mysql_query("SELECT * FROM membres WHERE id = ".$id);

Dans ce cas là, tu ne sera pas protegé malgre l'utilisation de ces fonctions; on peut très bien faire une injection SQL (union par exemple), sans utiliser le moindre guillemet ou caractère spécial.

Et la variable n'est pas vérifiée ça passera.

Un intval règle le problème (oui pour les puristes (on m'avait même dit que je devais faire une regex, et vérifier que le nombre ne soit pas trop haut... XD), certains trucs passeront mais j'aimerai qu'on me montre une fois si l'on peut faire une injection SQL sans la moindre lettre rien qu'avec des chiffres, ça risque d'être dur... XD).

Enfin je ne suis franchement pas l'expert en la matière. Si les experts peuvent confirmer ou corriger ce que je dit, ça serait sympa. ^^