Discussion :

[geekforever]

Bonjour,

Je développe une application en PHP faisant appel fortement à une BD.
Mon problème est que je ne peux pas employer de Framework (ne me demandez pas pourquoi ) qui me faciliterait le coté "Sécurité" pour les injections XSS / SQL

Exit les fonctions pg_escape_string ou htmlspecialchars_decode...
Il faudrait donc que j'intègre une classe de filtrage des données POST.
Après maintes recherches, je ne trouve pas la réponse à ma question:

Quelles classes / scripts utiliser pour vérifier les données provenant de formulaires ?

J'ai entendu parler des fonctions SANITIZE de PHP et de HTML Purifier. Que me conseilleriez vous ?

Et que pensez vous de cette fonction :

Code :

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

1
2
3
4
 
function SecurePost($PostVar) {
return addslashes(htmlspecialchars(mysql_escape_string(stripslashes(strip_tags($PostVar)))));
}

[sabotage]

Exit les fonctions pg_escape_string ou htmlspecialchars_decode...

Je n'ai pas compris pourquoi

Et que pensez vous de cette fonction

Que c'est une bouillie qui mélange tout.
- a quoi sert le stripslashes ?
- mysql_escape_string a été remplacé par mysql_real_escape_string
- si le but est de faire une insertion dans une base de données, le htmlspecialchars ne sert à rien.

[Eric2a]

Salut,

+1 Sabotage.

Prenons un exemple avec une donnée issue d'une requête HTTP POST.

Code :

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

$message=(isset($_POST['message']))?$_POST['message']:'';

On commence par vérifier si les guillemets magiques sont activés.

Qu'est-ce que les guillemets magiques?
Lorsque cette directive est active, les guillemets simples ', les guillemets doubles ", les antislashs \ et les caractères nul NULL sont protégés automatiquement avec un antislash. C'est le même résultat que celui de la fonction addslashes().

Avertissement : Cette fonctionnalité est OBSOLETE depuis PHP 5.3.0

Source : les guillemets magiques

Si c'est le cas, il nous incombe de supprimer les anti-slash en trop.

Code :

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

if(@get_magic_quotes_gpc())$message = stripslashes($message);

La présence du caractère @ permet de ne pas avoir de message d'avertissement pour les version de PHP 5.3.0 et supérieures.

À ce stade, $message contient le texte tel qu'il a été saisi dans le formulaire.

S'il le texte est destiné à être inséré dans une base de donnée, il faut protéger cette dernière à l'aide de mysql_real_escape_string().

Code :

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

$message_SQL = mysql_real_escape_string($message);

S'il le texte est destiné à être inséré dans une page HTML, il faut protéger cette dernière à l'aide de la fonction htmlspecialchars() ou de la fonction htmlentities().

Code :

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

$message_HTML = htmlspecialchars($message,ENT_QUOTES);

À voir également Le Filtrage des données.

[geekforever]

Merci pour vos réponses.

- Si je résume:
Un "mysql_real_escape_string()" / "pg_escape_string()" à l'insertion dans une base de données.
Un "htmlspecialchars()" à l'affichage des données provenant d'une BD.
Ces deux fonctions déployées, elles contreraient les injections SQL et XSS.

- En faisant des recherches sur le net, je constate des avis contradictoires, par exemple si je me réfère à http://techpad.co.uk/content.php?sid=86, ils recommandent d'utiliser une fonction similaire à la fonction "SecurePost" postée plus haut.

- D'où mon idée d'utiliser les fonctions de filtrage de données "Sanitize" assez récentes de PHP.

[sabotage]

Moi je trouve cela très discutable d'introduire du texte formaté html dans une base de donnée.
Mais c'est sur que dans la vie courante, en dehors de la perte d'espace, ça ne sera jamais un problème.

Par contre la combinaison des 3 trim, la je ne vois pas du tout.

[Eric2a]

Ces deux fonctions déployées, elles contreraient les injections SQL et XSS

Oui mais séparemment.

Un "mysql_real_escape_string()" / "pg_escape_string()" à l'insertion dans une base de données.

Ces fonctions suffisent à contrer les injections SQL.

Un "htmlspecialchars()" à l'affichage des données provenant d'une BD.

Oui mais attention... quelque soit la provenance des données (formulaire, fichier, BDD, ...).

La fonction sanitize() ci-dessous permet la convertion en fonction du paramètre $html :

$html = false
On empêche les injections SQL dans la base de données

$html = true
On empêche les codes malveillants d'être interprétés dans la page HTML

Un contenu balisé étant "inoffensif" après l'appel à la fonction htmlspecialchars, il est préférable de rendre sa suppression facultative.
Le paramètre $strip à true nous permet de supprimer ces balises.

Code :

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

1
2
3
4
5
6
7
8
9
function sanitize($str,$strip=false,$html=false){
	$s=trim($str);
	if($strip)$s=strip_tags($s);
	return ($html)?htmlspecialchars($s):mysql_real_escape_string($s);
}
 
$str = sanitize($texte,false,false); // On se protège des injections SQL
 
$str = sanitize($texte,false,true); // On se protège des attaques XSS

Edit : Correction d'une faute de saisie dans le code.

[geekforever]

OK merci à tous.

[geekforever]

Voici ce que j'utilise au final, avant de faire tout traitement sur des valeurs Post

Code :

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

1
2
3
4
5
foreach ($_POST as $key => $value) {
 	   if ( !is_numeric($value) ) {
		$_POST[$key] = addcslashes(pg_escape_string($value), '%_');
	}
}

sous oublier un htmlentities pour l'affichage...