Discussion :

[ChriGoLioNaDor]

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...

[Yoshio]

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.

[fallais]

Moi je ferais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

AddSlashes(htmlentities($ta_variable));

Avec ca, tu limites deja grandement les attaques de base

[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.

[SpiritOfDoc]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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;
	}

[zyongh]

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

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[fallais]

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.

[kaymak]

Salut,

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 :/

Moi je ferais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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...

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