[Réseau] addslashes, htmlentities, mysqli_real_escape_string, preg_quote

Bonjour,

J'ai des variables que j'utilise partout dans ma page ($section et $action). Je les utilise à la fois dans mes requêtes SQL et dans mon code php, mais jamais en affichage.

Conscient des précautions à prendre au niveau de la sécurité, je veux échapper les caractères "dangereux" de ces variables, mais j'aimerais le faire une fois pour toute au début de mon script, afin d'être certain de ne pas oublier de le faire, le moment venu :p On n'est jamais à l'abris d'un oubli!

Sachant que le contenu de ces variables est sensé n'être que du texte (a-z, A-Z, 0-9, "-" et c'est tout), quelle fonction serait la plus conseillée pour sécuriser mes variables?

J'ai pensé utiliser $section=preg_replace('^[-0-9a-zA-Z]*','',$section); mais pour tout vous dire, je m'emèle un peu les pinceaux parmis toutes les méthodes possibles pour sécurisez les données!

Qu'en pensez-vous? Pourriez-vous aussi m'indiquer les différences entre toutes ces méthodes?

A ce que j'ai compris,
- html_entities est indiqué lors de l'affichage de données, afin d'éviter l'éxécution de scripts (style javascript).
- addslashes n'est à utiliser que lorsqu'il n'existe pas de fonction de sécurisation liée à la BDD qu'on utilise
- mysqli_real_escape empêcherait les failles SQL.
Mais par exemple, est-ce que le fait d'utiliser html_entities me permettrait à la fois dempêcher les scripts, et les failles SQL, là je ne sais pas...

htmlentities() est utilisé seulement lors de l'affichage.

mysql_real_escape_string pour empecher les injection SQL avec mysql.
Il y a PDO aussi qui protège bien des requète SQL.

addslashes() faut pas l'utiliser, ton cas n'existera jamais.

Moi je ferais :

Code:

---

AddSlashes(htmlentities($ta_variable));

---

Avec ca, tu limites deja grandement les attaques de base :)

N'importe quoi ...

Une sert a contrer les injection SQL (d'un facon tres mauvaise), l'autre permet de securisé l'affiche de donnée.

Je te donne la méthode que j'utilise ... Certains, sûr d'eux mêmes ne répondront que ceci : "Pfff n'importe quoi, s'pas comme ça que j'fais moi, ça peut pas être bien !". D'autres, prendrons surement la peine de m'expliquer si je me trompe ou non.
Bien qu'au final, se tromper est dur puisqu'ici il s'agit de sécurité, et elle n'est jamais absolue.

Tout d'abord, j'ai cette fonction, qui est dans un fichier qui est inclue à chaque fois que je traite des données venant d'un utilisateur.

Code:

---

1 2 3 4 5 6

function protect_basique($variable) {   return htmlspecialchars(addslashes($variable));   }

---

Rien de bien méchant, mais cela remplaces les < et >, et ça évite certains problèmes, au niveau des comparaisons etc ...

Elle ne déforme pas la variable donnée, elle en rend juste une nouvelle, je peux donc, lors de l'inclusion SQL, utiliser mysql_(real_)escape_string() sachant que cette dernière requière absolument une connexion MySQL.

Il est intéressant d'utiliser htmlentities() avec les $_SERVER et plus particulièrement PHP_SELF.

Maintenant on dit qu'il faut faire place à la fonction SQL, et éviter d'utiliser addslashes() ... (Quand présence d'une connexion)

L'utilisation des ereg() peut-être très apprécié quand on sait à quoi doit ressembler la variable.

Il y a aussi la fonction is_numeric(), et quelques autres il me semble.

Voilà, bonne soirée.

[Edit] : Une autre fonction (trouvé dans joomla) qui peut être utile :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

function cleanText ( &$text ) { $text = preg_replace( "'<script[^>]*>.*?</script>'si", '', $text ); $text = preg_replace( '/<a\s+.*?href="([^"]+)"[^>]*>([^<]+)<\/a>/is', '\2 (\1)', $text ); $text = preg_replace( '/<!--.+?-->/', '', $text ); $text = preg_replace( '/{.+?}/', '', $text ); $text = preg_replace( '/&nbsp;/', ' ', $text ); $text = preg_replace( '/&amp;/', ' ', $text ); $text = preg_replace( '/&quot;/', ' ', $text ); $text = strip_tags( $text ); $text = htmlspecialchars( $text );   return $text; }

---

Exemple de récupération d'une variable transmise par un formulaire (method=POST)

Code:

---

$nom_variable = trim(htmlspecialchars(strip_tags($_POST['nom_variable']), ENT_QUOTES));

---

Citation:

---

Envoyé par Yoshio

N'importe quoi ...

Une sert a contrer les injection SQL (d'un facon tres mauvaise), l'autre permet de securisé l'affiche de donnée.

---

Suffisant.

Salut,

Citation:

---

Conscient des précautions à prendre au niveau de la sécurité, je veux échapper les caractères "dangereux" de ces variables, mais j'aimerais le faire une fois pour toute au début de mon script, afin d'être certain de ne pas oublier de le faire, le moment venu :p On n'est jamais à l'abris d'un oubli!

---

A mon sens, tu prends le problème par le mauvais bout. A quoi bon protéger une variable d'une possible attaque xss si celle ci n'est jamais affiché pour l'utilisateur ? Ou encore pourquoi protéger une variable d'une possible injection SQL si celle ci n'est jamais insérée dans une requete.
Clairement, c'est un idiotie ( ne pas prendre mal...) qui ne t'apporteras que des problèmes.
Il n'y à qu'a voir la directive magic_quote qui à un peu le même esprit et qui devine quoi, va être abandonner avec php6.
Ceci car l'équipe PHP s'est rendu compte que cela posait plus de problèmes qu'elle n'en résolvait réellement.
Il faut agir au cas par cas, la solution unique n'existe pas dans ce domaine.

Donc maintenant tu peux t'attaquer à la protection de tes données.

Pour les injections SQL, selon ta couche d'accès aux données, il existe différents fonctions. Mais d'une manière générales on retiendra que toutes les bonnes solutions font appel des fonctions php qui délégue la tâche aux drivers e la BDD (ce qui à chaque fois nécessite d'avoir prélablement créée une connexion à une bdd).
Donc les addslashes ect, on oublie. A la place se sera mysql_real_escape_string pour mysql, mysqli_real_escape_string pour mysqli ect ect
Pour PDO, cas particulier, les chaines ne sont protégées que lorsque la requete est préparée.
Si la requete est executée on the fly, tu prends tes propres risques.

Pour sécuriser tes variables qui seront affichés sur la sortie standard, tu as deux fonctions citées plus haut. htmlentities et striptags.
Clairement, si tu ne veux pas de balisages dans ton texte utilise striptags.
Utiliser htmlentities pour protéger ces variables c'est en faire un usage détourner qui n'à pas toujours de sens :/

Citation:

---

Envoyé par Elwyn

Moi je ferais :

Code:

---

AddSlashes(htmlentities($ta_variable));

---

Avec ca, tu limites deja grandement les attaques de base :)

---

Encore une fois il n'y à vraiment pas de meilleure remarque que...

Citation:

---

Envoyé par Yoshio

N'importe quoi ...

Une sert a contrer les injection SQL (d'un facon tres mauvaise), l'autre permet de securisé l'affiche de donnée.

---

bye

Citation:

---

Envoyé par kaymak

Encore une fois il n'y à vraiment pas de meilleure remarque que...

---

Merci de me soutenir :aie:

AddSlashes empeche de bloquer le script en incluant un ' ou "
htmlentities empeche d'y inclure ensuite du code html

Je dis donc largement suffisant :) Detourné mais suffisant :)

+1 pour kaymak !

Puisqu'Elwyn semble camper sur ses positions (ceci dit addslashes ne rajoutent pas des quotes :roll:) :
Addslashes n'est pas la solution à tous les maux et je dirais même à aucun : c'est un "faux amis". Prenons un exemple, vous offrez un champ de recherche à vos utilisateurs où vous, en tant que développeur, utilisez une expression régulière derrière pour diverses raisons (insensible à la casse, correspondance partielle, ...). Appliquez addslashes à ce motif et vous verrez que ce traitement ne correspond pas à vos données (preg_quote serait par exemple une solution puisqu'elle est prévue pour échapper tous les métacaractères). Revenons en à nos moutons : pour la base de données c'est exactement la même chose, qui est mieux placé pour procéder à l'échappement de l'ensemble des caractères spéciaux que le SGBD lui-même ? D'autant plus qu'ils varient d'un SGBD à un autre !

D'autre part, si les fonctions magic_quote sont actives et que vous rajoutez bêtement (disons-le) des addslashes ou toute fonction d'échappement vous allez vous retrouver avec des backslashs en trop. Puis on prend la mauvaise habitude d'ajouter des stripslashes un peu partout et de manière injustifiée. Bref, de quoi tourner en rond indéfiniment. La solution lorsque c'est possible et qu'on peut configurer son environnement c'est de désactiver ces fonctionnalités et de traiter soi-même les données en fonction de leur finalité, de leur origine et de leur destination. Si on en a pas le choix, rien ne nous empêche de faire du code portable et sécurisé.

Vivement PHP 6 qui va remettre de l'ordre dans tout cela et dans un sens aux détriments des débutants :aie:

Je campe pas sur mes positions je dis juste que je ne me suis jamais vraiment penché sur le probleme des attaques bidons, j'utilisais donc jusque la un moyen detourné, mais efficace (en tout cas dans le cadre de mon site). Mais apres avoir etudier la fonction mysql_real_escape_string(); elle commence a bien me plaire :P
Je vais donc reconsiderer mon code :)