[Sécurité] Sécurité de connection

**Anduriel** · 22/01/2006, 18h12

Salut,

Je me demandais: est ce que chez tous les hébergeurs les quotes sont interdits dans le choix des pseudo et mots de passe, ou mieux faut-il que je fasse un stripslashes des données envoyées par formulaire avant de me connecter ?
Merci

Invité · 22/01/2006, 21h16

dans tous les cas, si ton SGBD est MySQL, l'utilisation de mysql_real_escape_string() est plus que recommandée pou réviter toute attaque par injection SQL... ;-)

**Mr N.** · 22/01/2006, 21h22

Quel est le lien entre ton hébergeur et le choix de pseudo/mot de passe dans ton application ?
A la rigueur qu'il désactive des fonctions je veux bien, mais je vois pas comment il pourrait empecher de mettre une quote dans le pseudo du pauvre visiteur...

Tourne toi plutot vers ton application

**psychoBob** · 22/01/2006, 21h35

Code :

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

dans tous les cas, si ton SGBD est MySQL, l'utilisation de mysql_real_escape_string() est plus que recommandée pou réviter toute attaque par injection SQL...

htmlentities est encore mieux, non ? Ou en tout cas ça fait pareil, avec des trucs en bonus.

**Mr N.** · 22/01/2006, 21h42

Ce n'est pas du tout le même usage !
htmlentities convertit tout caractères en entités html si possible
alors que mysql_real_escape_string est concue spécialement pour prévenir toute injection sql.

**psychoBob** · 22/01/2006, 21h47

oui mais htmlentites prévient aussi les injections sql puisqu'elle place un / devant les '.

Ou alors il faut que je mysql_real_escape_string les données de mes formulaires, en plus de les htmlentiter !

**Mr N.** · 22/01/2006, 21h51

Il n'y a pas que le ' qui soit problematique sous mysql, sinon un simple addslashes suffirait... regarde la liste des caractères qui sont échappés par la dite fonction :
http://php.net/mysql_real_escape_string

Et regarde l'exemple 3 =>

Cet exemple démontre la méthode la plus propre pour envoyer une requête à la base....

**psychoBob** · 22/01/2006, 21h57

Bon

Alors tu me conseilles de passer d'abord les variables par htmlentites puis par mysql_real_escape_string? Et comment fait-on pour afficher le message sans les / ajoutés par mysql_real_escape_string? (désolé c'est pas mon post, mais j'en profite ça m'intéresse

).

Parce que jusqu'ici je faisais

Code :

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

1
2
3
4
//filtrage du contenu du formulaire
$V=htmlentitites($_POST[V])
//affichage dans l'espace de vérification
$V=stripslashes($V)

alors maintenant j'ajoute
$V=mysql_real_escape_string($V);
mais ça me recole des /

Mais de toute façon, on ne peut pas injecter une requête sql sans passer par les balises <?php ?>, non ? donc comme elles sont désactivées par htmlentites, c'est fichu. Je me trompe ?

**edit**
Avant d'envoyer les données dans la base, je les refiltre par htmlentities après qu'elles aient été affichées à l'aide de stripslashes.

Si je fais ça, c'est crétin, non :

Code :

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

1
2
3
4
5
6
7
8
9
10
 $contenuC=mysql_real_escape_string($contenuC);
  $contenuC = htmlentities($contenuC);
  $contenuC=stripslashes($contenuC);
   $contenuC=stripslashes($contenuC);
    $contenuC=stripslashes($contenuC);
//maintenant j'affiche, 
puis avant l'insertion définitive dans la base je refais
$contenuC=mysql_real_escape_string($contenuC);
  $contenuC = htmlentities($contenuC);
//puis quand je récupère les données depuis la base, je les repasse par stripslashes.

Pour la deuxième partie, ça me semble cohérent, mais pour la première, c'est un peu inutile non ?
(L'idée est de prévisualiser un commentaire puis de l'envoyer dans la base, la première partie concerne le passage entre le formulaire et la prévisualisation, partie dans laquelle il n'y a pas encore d'insertion dans la base).

**Mr N.** · 22/01/2006, 22h24

Attention, ici on parle d'injection sql. '<?php' n'a rien à voir avec une requête sql.
Personnelement je fonctionne de la manière suivante :
L'utilisateur tape une chaine "naturelle" : L'orient
PHP recoit et applique un coup de stripslashes suivant la configuration (magic_quotes)
Si je sors directement $_GET['var'], j'obtient : L\'orient
Donc je teste si magic_quotes est à on, et j'applique un stripslashes : L'orient
A partir de maintenant je travaille, indépendemment de la config, avec une chaine naturelle.
Je peut l'écrire directement au navigateur dans un div par exemple, je peux faire des stats dessus, ...
Je peux aussi l'insérer dans mysql
dans ce cas là si c'est un numeric, je touche à rien, sinon mysql_real_escape_string + j'ajoute des quotes autour
Quand je récupère depuis la bd, apres un mysql_query, j'obtiends une chaine naturelle (sauf configuration spéciale mais je suis jamais tombé dessus)
Je peux afficher directement la variable à l'utilisateur, ou faire des stats dessus, ou ...

Ce scénario regarde seulement mysql. pour d'autres attaques (de tye XSS?), ils faut faire un traitement supplémentaire (strip_tags, htmlentities, ...) soit à l'affichage de la variable, soit une fois pour toute avant insertion dans la bd. Mais encore une fois, ca n'a rien à voir avec les injections sql.

**psychoBob** · 22/01/2006, 22h46

Ok je ne pensais pas que l'on puisse insérer une requête sql dans un formulaire sans l'encadrer par <?php ?> (pour une page en php).

Je viens de faire un test:
J'ai inséré deux foisle même code pirate dans ma base de donnée : filtré une fois avec htmlentities, puis une fois avec mysql_real_escape_string.

Dans la base, le résultat est strictement le même dans les deux cas, sauf qu'avec htmlentities, les < et autres & sont encodées, mais les / sont en même nombre au même endroit.

J'ai quand même placé un htmlentitities($v) suivi d'un mysql_real_escape_string(), au cas où, mais est-ce utile ?

**psychoBob** · 22/01/2006, 22h52

Et là je viens d'insérer le même bout de code mais en le filtrant d'abord par htmlentities puis par mysql_real_escape_string :

Résultat strictement identique dans la base de données, par rapport à l'insertion filtrée uniquement par htmlentities.

Conclusion personnelle et modeste : mysql_real_escape_string n'apporte aucune sécurité supplémentaire par rapport à htmlentities, au contraire puisqu'elle ne protège pas des attaques xss, mais par contre est utile pour ne pas encoder les caractères spéciaux.

htmlentities =mysql_real_escape_string + encodage des caractères spéciaux ?

**Mr N.** · 22/01/2006, 23h01

J'ai comme l'impression de parler dans le vide...

sans savoir ce qui se trame derrière ces fonctions, analyse leur nom :
htmlentities
mysql_real_escape_string
Pas besoin de tergiverser cent sept ans. deux fonctions pour deux usages différents. Tu peux mettre autre chose que du html dans une base de données, et le contenu d'une base de données n'est pas forcément à destination d'un flux html.

**psychoBob** · 22/01/2006, 23h07

Bon d'accord, mysql_real_escape_string a ses raisons d'être que ma raison ignore, cela étant je viens bien de vérifier dans la base et j'insiste :

Mon code pirate avec requêtes complètes et tout ce qui s'en suit (c'est pas le miens je l'ai récupéré sur un tutoriel, de toute façon c'est un code basique rien de plus) et bien mon code donc, est slashé de la même manière avec htmlentities qu'avec mysql_real_escape_string.

Donc même si j'ignore les subtilités de ces fonctions, je suis en droit de penser qu'htmlentities protège la base de données des injections sql de la même manière que mysql_real_escape_string.

Je viens de répéter pareil aussi mais bon, j'ai toujours pas compris pourquoi htmlentities est pas mieux que mysql_rea_escape_string, question sécurité pure.

**Mr N.** · 22/01/2006, 23h10

C'est quoi ta requête pirate ?

**Death83** · 22/01/2006, 23h11

un stripstags ne suffirait pas?

**ePoX** · 22/01/2006, 23h14

un stripstags ne suffirait pas?

Rien à voir, striptags sert à retirer les balises. Faut s'en servir pour éviter les vols de session cookies ect. failles XSS je croit.

Aller Mr N., Aller Mr N., Aller Mr N., Aller Mr N., Aller Mr N.

**psychoBob** · 22/01/2006, 23h19

ça c'est ma requête pirate recopiée d'un manuel php (bien sur elle ne pirate rien, le but est juste de constater les effets des fonctions en questions sur elle, une fois qu'elle est insérée dans la base):

Code :

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

1
2
3
4
5
6
7
8
9
10
11
<?php
 
$query = "SELECT * FROM users WHERE user='{$_POST['username']}' AND password='{$_POST['password']} '" ;
mysql_query ( $query );
 
 
$_POST [ 'username' ] = 'aidan' ;
$_POST [ 'password' ] = "' OR ''='" ;
 
echo $query ;
?>

ça c'est le résultat une fois dans la base, filtré par htmlentities :

Code :

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

1
2
3
4
5
6
7
8
9
10
&lt;?php
 
$query = \&quot;SELECT * FROM users WHERE user=\'{$_POST[\'username\']}\' AND password=\'{$_POST[\'password\']}   \'\&quot; ;
mysql_query ( $query );
 
$_POST [ \'username\' ] = \'aidan\' ;&lt;br /&gt;
$_POST [ \'password\' ] = \&quot;\' OR \'\'=\'\&quot; ;
 
echo $query ;
?&gt;

ça c'est le résultat dans la base, filtré par mysql_real_escape_string

Code :

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

1
2
3
4
5
6
7
8
9
<?php 
 
$query = \"SELECT * FROM users WHERE user=\'{$_POST[\'username\']}\' AND password=\'{$_POST[\'password\']}  \'\" ; 
mysql_query ( $query ); 
$_POST [ \'username\' ] = \'aidan\' ; 
$_POST [ \'password\' ] = \"\' OR \'\'=\'\" ; 
<br />
echo $query ; 
?>

Et ça c'est le résultat dans la base, filtré par les deux à la suite:

Code :

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

1
2
3
4
5
6
7
8
9
10
&lt;?php
$query = \&quot;SELECT * FROM users WHERE user=\'{$_POST[\'username\']}\' AND password=\'{$_POST[\'password\']}  \'\&quot; ;
mysql_query ( $query );&lt;br /&gt;
 
$_POST [ \'username\' ] = \'aidan\' ;&lt;br /&gt;
$_POST [ \'password\' ] = \&quot;\' OR \'\'=\'\&quot; ;
 
echo $query ;
 
?&gt;

J'ai juste viré les <br/> encodés ou non selon les cas.

**Mr N.** · 22/01/2006, 23h25

Envoyé par psychoBob

j'ai toujours pas compris pourquoi htmlentities est pas mieux que mysql_rea_escape_string, question sécurité pure.

Voici pourquoi :

Code :

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

1
2
3
4
5
6
<pre><?php
	$var = "L'orient";
	var_dump($var);
	var_dump(htmlentities($var));
	var_dump(mysql_real_escape_string($var));
?>

Ca donne :

Code :

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

1
2
3
string(8) "L'orient"
string(8) "L'orient"
string(9) "L\'orient"

Le comportement n'est pas identique, htmlentities ne m'as pas échappé l'apostrophe => il ne protège pas des injections sql.
CQFD

La on va me dire qu'on peut échapper les apostrophes avec ENT_QUOTES
Je suis d'accord, mais quid des autres caractères propres à mysql :

Code :

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

NULL, \x00, \n, \r, \, ', " et \x1a

:

**psychoBob** · 22/01/2006, 23h28

Oui j'ai pas tout compris mais bon, pourquoi dans ce cas, htmlentities n'a pas échappé ta chaîne?

Et sinon... soyons pragmatique:

Si je fais ça avant l'insertion dans la base, t'es ko ?

Code :

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

1
2
3
 
$contenu= htmlentities($_POST['$contenu']);
$contenu= mysql_real_espace_string ($contenu).

**Mr N.** · 22/01/2006, 23h38

Je sais pas ce que tu entends par ko, mais vu l'heure, oui je suis ko

Si tu fais ça, tu transforme les caractères spéciaux html en entités (XSS?) et tu échappent les caractères spéciaux mysql (injections sql).

[Sécurité] Sécurité de connection

Langage PHP

Discussions similaires

Partager

Partager