Filtrage Post PHP - Sécurité

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:

---

1 2 3 4

function SecurePost($PostVar) { return addslashes(htmlspecialchars(mysql_escape_string(stripslashes(strip_tags($PostVar))))); }

---

Citation:

---

Exit les fonctions pg_escape_string ou htmlspecialchars_decode...

---

Je n'ai pas compris pourquoi

Citation:

---

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.

Salut,

+1 Sabotage.

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

Code:

---

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

---

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

Citation:

---

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 : :arrow: les guillemets magiques

---

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

Code:

---

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:

---

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

---

$message_HTML = htmlspecialchars($message,ENT_QUOTES);

---

À voir également :arrow: Le Filtrage des données.

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.

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.

Citation:

---

Envoyé par geekforever

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

---

Oui mais séparemment.

Citation:

---

Envoyé par geekforever

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

---

Ces fonctions suffisent à contrer les injections SQL.

Citation:

---

Envoyé par geekforever

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:

---

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.

OK merci à tous.

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

Code:

---

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