[Sécurité] Injections SQL

[sway]

Bonjour,

Depuis peu, des gens pas très cools me font des injections sql par le biais de page de connexion sur mon serveur. J'ai lu la doc sur le cross site scripting mais je reste coincée au niveau de l'intégration de htmlspecialchars dans mon code. Au lieu de m'afficher le texte normal, il m'affiche tout ainsi que le nom des balises sur ma page !!!

Au départ j'avais ce code là :

Code :

1
2
3
4
5
6
7
if (!$_SESSION["membre_prive"]) {
 
$affiche_login ="Utilisateurs privés : &nbsp;Identifiant &nbsp;<input id='id' size='16' name='id' /><br />Mot de passe &nbsp;<input id='motdepasse' type='password' size='10' name='motdepasse' /> &nbsp;<input type='submit' value='Go' name='submit2' /><br />Pas encore <a href='./membres.php'>membres ? </a>&nbsp;<a href='./Aide.php'>Besoin d'aide ?</a>";
   }
   else
   {
$affiche_message ="<FONT SIZE='1' FACE='Arial' COLOR='#426F85'><B>&nbsp; Bonjour !</B></FONT>";

Tout s'affiche normalement, mes input sont niquels etc...
Puis j'ai mis à jour.. Et maintenant mes input ne s'affichent plus en "graphique" html mais en texte !!! Et les autres balises pareil du genre <font face="verdana">Bonjour !</font> au lieu de juste "bonjour !" Je suis vraiment perdue

Code :

1
2
3
4
5
6
7
8
9
if (!$_SESSION["membre_prive"]) {
 
htmlspecialchars($affiche_login);
$affiche_login = htmlspecialchars("Utilisateurs privés : &nbsp;Identifiant &nbsp;<input id='id' size='16' name='id' /><br />Mot de passe &nbsp;<input id='motdepasse' type='password' size='10' name='motdepasse' /> &nbsp;<input type='submit' value='Go' name='submit2' /><br />Pas encore <a href='./membres.php'>membres ? </a>&nbsp;<a href='./Aide.php'>Besoin d'aide ?</a>", ENT_QUOTES);
   }
   else
   {
htmlspecialchars($affiche_message);
$affiche_message = htmlspecialchars("<FONT SIZE='1' FACE='Arial' COLOR='#426F85'><B>&nbsp; Bonjour !</B></FONT>", ENT_QUOTES);

[mikyfpc]

Salut,

Je ne comprends pas trop le rapport entre ton problème d'injection SQL et le code que tu donnes.

Pour les injections SQL, quand tu récupères des variables ( $_GET ou $_POST) tu peux faire

Code :

$tavariable = addslashes( $_GET[ "ta variable" ] );

Ensuite quand tu dois l'afficher, tu peux faire

Code :

$tavariable = stripslashes( $tavariable );

Ca devrait résoudre une grosse partie de tes soucis car cela va ajouter des slashes avant les quotes par exemples.

Mickaël

[Haze.]

C'est quoi cette manie de toujours vouloir appliquer des stripslashes() sur les variables en sortie de la base de données ?!
J'ai du voir ça une bonne douzaine de fois au moins...

Si les variables ont été correctement échappées avant insertion dans la BDD, alors aucun antislash ne doit être enregistré.
Généralement les gens utilisent un addslahes() en plus d'avoir les magic_quotes_gpc activées, ce qui fait qu'il y a un double échappement : en effet les magic_quotes ajoutent automatiquement un autre addslashes().
Du les variables PHP se retrouvent avec 3 antislashs au lieu d'un seul et ça oblige à appliquer un stripslashes() en sortie...
Si je rentre dans un formulaire (ou dans une variable dans l'URL) :
"test"

Avec les magic_quotes_gpc ça deviendra :
\"test\"

Et en plus le second addslashes() :
\\\"test\\\"

Absurde non ?!

Quant à la fonction htmlspecialchars() ou htmlentities(), on l'utilise après enregistrement, et non avant insertion dans la BDD, sinon on enregistre plein de caractères supplémentaires pour rien...

Autre chose encore : pour échapper les données, utilisez la fonction spécifique à votre BDD, et non addslashes(). Avec MySQL, il s'agit de mysql_real_escape_string().
Petit exemple avec un formulaire :

Code "PHP :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
if (!empty($_POST['var_1']) and !empty($_POST['var_2']))
{
	// on enlève les espaces en début et en fin de chaîne :
	$var_1 = trim($_POST['var_1']);
	$var_2 = trim($_POST['var_2']);
	// Si les magic_quotes sont activées, on enlève les antislashs
	if (get_magic_quotes_gpc())
	{
		$var_1 = stripslashes($var_1);
		$var_2 = stripslashes($var_2);
	}
	// Maintenant on peut échapper proprement les var
	$var_1 = mysql_real_escape_string($var_1);
	$var_2 = mysql_real_escape_string($var_2);
	// ..... OK pour insertion dans la BDD
}

Bon, pour en revenir au problème de sway, je doute que ta faille se trouve dans le morceau de code que tu nous a montré, en effet ce sont juste des chaînes de caractères que tu initialises toi même, elles ne contiennent aucun élément issu du navigateur du visiteur...

Protège toutes tes données issues des $_POST, $_GET et $_COOKIE comme avec mon exemple ci-dessus (si tu utilises MySQL bien sûr) et tu devrais être bien protégé contre les injections SQL (Pense aussi à intval() pour tes variables contenant un nombre entier).

[sway]

En fait apparemment d'après notre administrateur réseaux, la hackeur passe par cette page là pour faire son cross site scripting et tout casser ! Donc je me demandais s'il ne passait pas sur le serveur en envoyant des commandes par le biais de la case input du mot de passe et du login...

Je ne comprends vraiment pas j'ai bien veillé à mettre $_GET ou $_POST mais je vais rajouter $tavariable = addslashes( $_GET[ "ta variable" ] );

En tout cas merci pour les réponses rapides !!!!

[zvince]

Si il y a injection sql ou cross site scripting, ce n'est pas sur cette page, mais sur l'action page du login, si un hacker met des choses bizarres dans les champs id et password.
Un truc tout bête : contrôler la longueur des champs du formulaire. Si la longueur de l'id dans la bdd est 10, il ne faut pas accepter plus de 10 caractères. Idem pour le mot de passe.
On peut aussi chercher des mots comme SELECT, INSERT, DELETE, =, " ", null, not ... le plus simple est de limiter les caractères autorisés à l'inscription et de contrôler ça au login ...
mais bon, tout ça doit être dans la faq ...

[Yoshio]

http://a-pellegrini.developpez.com/t...tyle/#LIII.1.6

PDO c'est bien aussi pour gérer les acces en base de donnée.