a écrit :
function sanitizeString($var)
{
$var = stripslashes($var);
$var = htmlentities($var);
$var = strip_tags($var);
return $var;
}
quequ'un peut il m'expliquer ce que ceci apporte au niveau de la sécurité?
En vue d'un envoi à la base de données pour se prévenir des injections SQL, je voudrais presque dire
rien du tout ! Mais c'est quand même un peu méchant.
$var = stripslashes($var);
=> strip_slashes ne sert à rien si magic_quotes n'est pas activé... pire, ça fausse les entrées de l'utilisateur. C'est pas courant de saisir \' ou \" mais ça peut poser des problèmes si c'est du code, quelque part comme sur ce forum par exemple.
ET comme c'est une erreur d'activer magic_quotes sachant qu'il ne protège qu'à moitié et sachant qu'il va bientôt disparaître, c'est aussi faux d'utiliser strip_slashes
$var = htmlentities($var);
=> Ca, ça transforme les caractères comme ' et " en &apos et ". Alors en fait, oui, ça protège de 99% des injections SQL parce que ' et " n'apparaissent plus dans la string. Mais de un c'est pas 100% infaillible (il existe quelques injections faisables sans ' ni " dans certains cas), et de deux c'est une erreur d'appréciation parce que ça ne sert à rien de stocker ces caractères sous forme d'entité dans la base. C'est une question d'affichage et ça n'a vraiment rien à faire dans la base.
$var = strip_tags($var);
=> Ca ça sert doublement à rien. C'est censé supprimer les balises HTML. Une fois de plus ça concerne l'affichage pas la base, mais en plus le faire après htmlentities ne changera rien puisque tous les < et > auront été transformés en < et >.
La façon la plus simple pour se protéger
presque complètement contre les injections SQL, c'est d'utiliser les fonctions qui ont été prévues pour ça: PDO::quote, ou anciennement mysql_real_escape_string. Attention au fait que PDO::quote ajoute automatiquement des apostrophes au début et à la fin de la chaîne, pour qu'on puisse passer indifféremment des entiers et des strings directement à SQL sans plus se poser de question par après.
Pour faire mieux, on devrait même utiliser les requêtes préparées.
Sinon, si on a besoin de plus complexe pour plus de sécurité, la bible à suivre en la matière sur le web, c'est l'OWASP
https://www.owasp.org/
Le top 10 est remis à jour chaque année. A défaut d'utiliser leurs API, on peut au moins suivre leurs conseils. Pour ceux qui ont déjà un peu lu et étudié sur la sécurité, la plupart est du classique, du revu et du réchauffé, mais dans l'idéal on devrait toujours être conscient de tout ça. Même les meilleurs ont tendances à oublier, une petite relecture ne fait pas de mal.
Le plus important à retenir c'est qu'il y a deux principales familles de failles contre lesquelles il faut se protéger: les injections SQL, et les XSS. IL faut bien comprendre la différence entre les deux et à quels moments elles peuvent intervenir. A essayer de faire n'importe quoi n'importe quand, on ne sait plus vraiment quoi permet de protéger contre quoi et au final on ajoute plus de problèmes qu'on en résoud.
Là quand je vois qu'un livre propose htmlentities pour envoyer en base SQL, par exemple, ça me choque: ça me donne l'impression qu'on mélange les deux, qu'on n'a rien compris et qu'on essaye tout et n'importe quoi n'importe comment en espérant qu'on ne risque rien.
EDIT: Tiens, le forum ne supporte pas les liens en HTTPS ?
Modifié par QuentinC (06 Sep 2013 - 17:32)