sécurité - magic_quotes & addslaches()

[blue Mary]

Bonjour,

voilà je travail depuis 2 bonnes semaines sur un projet PHP.

Les tests sont effectués sur un serveur free, donc avec les magic quotes activés.

Ne sachant pas si ce sera le cas du serveur final j'ai fait la fonction qui suit:

function magicQuotes($txt) {
	   if(get_magic_quotes_gpc()) 
		 return $txt;
	  else
		 return addslashes($txt);
	}

Bref,

est il nécessaire de faire appelle a ma fonction sur chaque entrée utilisateur? (lourd à mettre dans le code, et pas du tout optimal pour le serveur) Ou seulement dans le cas de concaténation de chaine de caractères?

En principe je dirai le second, je vous voudrais être sûr de ne pas courir de risque.

Merci d'avance de vos réponses

[Sarc]

Les striptags sont aussi très utiles pour améliorer la sécurité, ça évite l'introduction de <script> dans les champs... Ca, tu peux l'utiliser uniquement pour les entrées assez longues, comme les textarea. Pour les apostrophes, c'est pour éviter les injonctions SQL il me semble, donc ça ne peut être réellement dangereux que quand il y a assez de caractères pour travailler, non ? J'avoue m'y connaître peu en question de hack, et donc les autres réponses m'intéresseront, mais c'est ce que j'imagine.

[petit-ourson]

Dire que je désactive systématiquement cette fonctionnalité (les magic quotes).

[blue Mary]

Justement je ne suis pas une spécialiste de la sécurité, donc avec les apostrophes est ce que je risque autre chose que les injections SQL?

Pour les magic quotes il est conseillé de les désactiver, et ne seront même plus présent dans PHP6 si je ne me trompe pas.

Cela est du a une question de performance, et le fait que les personnes écrivant des scripts PHP se reposent trop sur les magic quote négligeant (ou ignorant totalement) la partie sécurité... (corrigez moi si je me trompe)

Mais cela ne me fait pas vraiment avancer, est ce que l'on peut craindre autre chose que les injections SQL?

[hcplayer]

Je n'ai pas entendu parler d'autres attaques que les injection SQL si l'on désactive les magic quotes, par contre il me semble qu'une fonction existe déjà pour les empêcher : http://fr2.php.net/mysql_real_escape_string

Il me semble également que les magic quotes echappent les caractères provenant d'une source de donnée externe.

Tu as parfaitement raison pour ce qui est de php6 apparement : http://www.php.net/~derick/meeting-notes.html#magic-quotes

[blue Mary]

oui les magic échappent tout ce qui est externe, et pour ce qui est de mysql_real_escape_string je l'utilise déjà pour protéger mes requêtes.

Je me demandais justement si j'avai besoin de protéger mon code PHP plutot.

Mais de toute façon le serveur final est en PHP4 avec les magic_quotes d'activés donc j'ai viré ma fonction qui ne servait sans pas à grand chose de toute façon.

[shenron76]

Pour sécuriser ton site je te conseil d'appliquer un htmlspecialchars() sur chaque variable que tu récupères et qui sera enregistrée dans ta bdd. Concernant les injections SQL, il te suffit d'appliquer un mysql_real_escape_string() sur les variables récupérées avant de les enregistrer également ...

[Kioob]

Hello,

je vais tenter d'éclaircir un peu tout ça vu que cela semble encore flou.

Pour commencer prenons une requete SQL classique, faite au sein de PHP :

$requete = "select nom, prenom, email from utilisateur where login = '$login' and password = '$password' ";

Rien d'extraordinaire jusque là. Maintenant imaginons qu'un vilain visiteur ne saisisse pas un mot de passe classique mais quelque chose contenant des apostrophes... par exemple : toto' OR '1' ='1

On obtiendra donc la requete :

select nom, prenom, email from utilisateur where login = 'bidule' and password = 'toto' OR '1' ='1'

Et là aïe, ça coince : peu importe le mot de passe, la requête retournera un résultat. Et évidement, il y a bien d'autres possibilités.

L'idée de départ des "magic_quotes_gpc" était donc de se protéger de cela. Sauf que cela pose deux soucis : premièrement, magic_quotes_gpc se contente de faire un bête un addslashes() sur toutes les données, ce qui est loin d'être suffisant pour se protéger des injections SQL. Et secondement, magic_quotes_gpc est bête et méchant : il fait un addslashes() sur toutes les données entrantes, alors qu'il est rare qu'elles ne servent qu'à produire des requetes SQL.

Au final, pour vraiment se protéger d'une injection SQL on est donc obligés de faire un "stripslashes" (pour récupèrer la variable d'origine) suivi d'un mysql_real_escape_string (qui est la seule fonction échappant correctement les données pour MySQL). Galère non ?

Sans oublier que si vous voulez utiliser votre variable pour autre chose qu'une requete SQL, il faudra également y aller à coup de stripslashes...

Voilà pourquoi c'est supprimé de PHP 6 : les développeurs se croient à l'abri en utilisant cette "fausse sécurité" alors qu'il n'en est rien. Un comble non ?

La solution ? Désactiver magic_quotes_gpc, et toujours penser à utiliser mysql_real_escape_string quand c'est nécessaire.

Pour ce qui est de la portabilité du code, j'ai donc opté pour le contraire de la solution ci dessus : je fais des stripslashes sur toutes les données en entrée si magic_quotes_gpc était actif.

Ainsi cela implique un traitement supplémentaire (le stripslashes) que sur les serveurs "mal" configurés (1).

Cela donne par exemple :

<?php
if( get_magic_quotes_gpc() )
{
	gpc_walk( $_GET, 'stripslashes' );
	gpc_walk( $_POST, 'stripslashes' );
	gpc_walk( $_COOKIE, 'stripslashes' );
	gpc_walk( $_REQUEST, 'stripslashes' );
}

function gpc_walk( & $array, $fct )
{
	foreach( $array as $key => $item )
	{
		if( is_array( $item ) )
		{
			gpc_walk( $array[$key], $fct );
		}
		else
		{
			$array[$key] = $fct( $item );
		}
	}
}
?>

Voilou

(1) dans le cas d'un hébergement mutualisé, où l'on ne contrôle pas les scripts utilisés par le client, activer magic_quotes_gpc reste malgré tout le meilleur choix à mon avis :

- de toutes façons les scripts "bien fait" gèrent ça correctement

- si le script n'en tient pas compte, il vaut toujours mieux avoir une sécurité relative (addslashes) qu'aucune.

[petit-ourson]

Il n'est pas possible de désactiver les 'magic_quotes_gpc' via un ini_set ?

Je ne me souviens plus...

[Kioob]

Pas à ma connaissance non : pour faire un "ini_set", il faut que ton script ait débuté, et si c'est le cas c'est "trop tard", les variables d'entrée sont déjà modifiées.

Note : je viens de vérifier dans la doc, il était possible de modifier "ini_set" dans un script avant la version 4.3 de PHP. Mais ce n'est plus le cas désormais. Il reste néanmoins la solution du fichier .htaccess

Modifié 20 Septembre 2007 par Kioob