[php] Sécuriser les données de son formulaire - Sans abimer l'affichage ^^

J’ai naturellement plein de formulaires sur mon application en php, et naturellement je me pose la question des blems de sécurité, on m’a signifié que mysql_escape_string() était un bon début…

Seulement voilà, clairement et factuellement, sur une $string à afficher dans un textarea par exemple, quelle fonction je dois appliquer dessus avant de l’insérer dans ma base de données pour éviter des soucis grave niveau sécurité, et ensuite quelles fonctions je balance dessus à l’affichage pour pas me retrouver avec des \\\r\\n\\" et autres de ce style :slight_smile:

Merci par avance ^^

PS : comme lancer cette fonction à la volée sur toutes mes variables de formulaire ? là je fais :

$data = cleanup($_POST[‘data’]);

Mais des fois j’en ai genre 10-15 => c’est long :frowning:

Merci par avance !

Saluton,
Pour la deuxième partie de ta question je te recommande nl2br().

hum…

tout dépend de ce que tu fais et ce que tu as.

  1. toujours faire stripslashes si get_magic_quotes_gpc() renvoie true

C’est important de comprendre que PHP va - si magic_quotes_runtime - est activé échapper automatiquement toutes les variables GPC pour justement te prémunir contre les injections de code dans les requêtes.

Mais ça, ça bouffe plus des ressources et c’est pas une solution. Donc il faut d’abord inverser ce comportement (ou mieux désactiver la fonction via .htaccess ou php.ini)

  1. La GPC (get, post, cookie) contient une valeur de type entière, flottante ou booléenne? -> utilise le cast $_POST[‘foo’] = (int)$_POST[‘foo’];

Comme ça pas de problème avec la variable que ce soit en injectant dans xhtml+css, ou dans une base de données.

Pour les booléens, y a quand même une vérification à faire (oui : (bool) $_POST[‘foo’] == ‘machin’ renvoie true ou false, mais false == ‘’ si tu cast en string).

  1. Les GPC qui sont des chaînes doivent être traitées avec minuties :

a. injection dans une requête? alors il faut les passer avec un coup de mysql_real_escape_string, pg_escape_string, et ainsi de suite (le mieux étant d’avoir une classe qui fait tout ça)

b. injection dans un code PHP (eval, ou écriture de code php via fopen+fwrite) : addslashes si c’est une chaîne.

c. injection dans du code HTML ? htmlspecialchars si ça ne doit pas contenir de html, sinon tu peux laisser comme ça.

Pour ces mêmes chaînes, si tu les affiches dans du HTML, faut faire gaffe à ce que tu veux en faire : affichage dans un textarea => rien à faire. Sinon, faut voir si tu veux conserver les sauts de ligne => nl2br.

Voilà.

Sécuriser les GPC c’est pas compliqué, c’est automatiser le processus qui l’est :wink:

Tout ce qui est dans des formulaires est réaffiché dans des formulaires.

En effet en local magic quotes est désactivé, mais il doit être activé sur mon serveur distant, encore que je n’ai pas vérifié, ca doit expliquer l’écart d’affichage que j’ai entre mon portable et le serveur “live” de test :confused:

Le but n’est pas que cela soit ultra sécurisé, car en toute franchise je n’ai pas le temps de le faire, et c’est un utilisateur unique sur un poste local qui va employer mon script.

Ce que je veux éviter avant tout c’est des bugs liés aux " ’ et autres de ce genre…

ben justement :slight_smile: faut jarter les magic_quotes_gpc (tu fais une fonction stripslashes_gpc() et tu stripslashes les gpc dont tu te sers par défaut, ça fera rien au pire)

un peu de lecture ?

Article très intéressant je dois dire !

J’avoue que c’est pénible a comprendre et à appréhender ces histoires de magic quotes… bon donc en gros mon soucis c’est qu’en local j’ai pas magic quote d’activé, et que chez mon hébergeur c’est manifestement le cas, d’où la différence :confused:

Grrrr ^^

ok bon alors les injections SQL, html et autres n’étant pas possibles dans mon application, au sens où l’utilisateur unique ne va pas chercher à la planter car c’est son outil de travail et que s’il ne l’a pas il est grave dans la merde :smiley:

Donc en faisant simple je veux éviter essentiellement les bugs à l’insertion des données du formulaire dans la base de données, et les bugs d’affichage…

Donc on a pour faire simple :

Nom <input text>
Prénom <input text>
Adresse <textarea>

Quelles sont les étapes ? j’ai intégré un

if (1 === get_magic_quotes_gpc())

Pour vérifier que les magic quotes sont activées ou pas.

A partir de là, concrêtement, je fais quoi pour mes valeurs ?

si magic quotes est désactivée, alors je fais un addslashes avant insertion dans la base de données ?

Et ensuite pour réafficher je ferais un stripslashes (vouais parce que peut être que je vais pas réafficher uniquement dans un formulaire en définitive (font chier à tout changer tout le temps aussi :D)) ?

Désolé, j’ai un peu du mal à saisir comment ca marche et quelles sont les conséquences précises… on va y arriver ^^

alors, vla ce que ca donne :

fonction cleanup($string)
$string = htmlentities($string);
if (0 === get_magic_quotes_gpc())
{
    addslashes($string)
}
return $string;
}

Qu’en pensez vous ?

c’est faux.

Ton if sert à rien du tout, et c’est pas ça qu’il faut faire.

function cleanup($s) {
  if ( get_magic_quotes_gpc() )
    $s = stripslashes($s);
  return htmlentities($s);
}

pouf.

okay :slight_smile: je changerais :slight_smile:

le if fait rien ? j’ai pas inventé ce morceau de code pourtant, il était sur un site… http://www.expreg.com/rex_article.php?art=apostrophemagique

if (0 === get_magic_quotes_gpc())
{
addslashes($string)
}

-> test si get_magic_quotes_gpc est désactivé (avec en sus un opérateur d’équivalence pas forcément utile sur un truc booléen)
-> addslashes($string) : applique addslashes sur une chaîne et … n’en fait rien.

De plus, ce que tu veux, c’est conserver l’affichage normal. Que echo $_GET[‘foo’] avec foo=‘aa’ s’affiche bien tel que : ‘aa’ et pas tel que \‘aa\’. Donc c’est un stripslashes qu’il faut faire pour contrecarrer l’effet des magic_quotes.