Discussion :

[sinifer]

Bonjour,

Je regarde pour protéger mon site et j'ai mis ces fonctions, je voulais savoir si c'étais bon et bien protégé comme sa.

En début de chaque page

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
//Contre injection xss et sql
if(!empty($_POST)){
	$_POST = sanitize($_POST);
	$_POST = sanitize_trim($_POST);
	$_POST = sanitize_strip($_POST);
}
 
if(!empty($_GET)){
	$_GET = sanitize($_GET);
	$_GET = sanitize_trim($_GET);
	$_GET = sanitize_strip($_GET);
}

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
 
 
function sanitize($input){
    if(is_array($input)){
        foreach($input as $k=>$i){
            $output[$k]=sanitize($i);
        }
    }
    else{
        if(get_magic_quotes_gpc()){
            $input=stripslashes($input);
        }       
        $output=mysql_real_escape_string($input);
    }   
 
 
	return $output;
}
 
 
function sanitize_trim($input){
    if(is_array($input)){
        foreach($input as $k=>$i){
            $output[$k]=sanitize_trim($i);
        }
    }
    else{      
        $output=trim($input);
    }   
	return $output;
}
 
//contre injection xss
function sanitize_strip($input){
    if(is_array($input)){
        foreach($input as $k=>$i){
            $output[$k]=sanitize_strip($i);
        }
    }
    else{     
        $output=strip_tags($input);
    }   
	return $output;
}

Merci de votre aide

[sabotage]

On ne peut pas appliquer ces fonctions de manières systématiques.

mysql_real_escape_string(), en dehors d'être obsolète, ne sert qu'à l'ajout de données dans une requête SQL ; je suppose que toutes tes données POST et GET ne finissent pas dans une requête.

[Benjamin Delespierre]

C'est un protection un peu lourde ce que tu nous fais là, tu ferais mieux d'utiliser les filtres et les requêtes préparées.

Exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
<?php
 
// filtrer & nettoyer les valeurs obtenues
$data = filter_input_array(INPUT_POST, array(
    'nom'    => FILTER_SANITIZE_STRING,
    'prenom' => FILTER_SANITIZE_STRING,
    'age'    => FILTER_VALIDATE_INT,
    'mail'   => FILTER_VALIDATE_EMAIL,
));
 
// y a t'il des valeurs incorrectes ?
if ($error_fields = array_keys($data, false, false)) {
 
    // retourner sur le formulaire et afficher les messages d'erreur
    afficher_formulaire($error_fields);
}
 
// enregistrer en base (on suppose que $pdo est un objet de la classe PDO)
$stmt = $pdo->prepare('INSERT INTO users (nom,prenom,age,mail) VALUES (:nom,:prenom,:age,:mail)');
 
if (!$stmt->execute($data)) {
 
    // erreur d'insertion en base
    afficher_erreur($stmt);
}
 
// sortir les données de la base et les afficher
$stmt = $pdo->query('SELECT nom,prenom FROM user WHERE id=1');
 
list($nom, $prenom) = $stmt->fetch(PDO::FETCH_NUM) + array('', '');
 
// nettoyer en sortie
$nom    = filter_var($nom, FILTER_SANITIZE_SPECIAL_CHARS);
$prenom = filter_var($prenom, FILTER_SANITIZE_SPECIAL_CHARS);
 
echo "Bonjour $prenom $nom";

[sinifer]

Merci de vos réponses.

On va dire que 90% de mes Post et Get finissent dans une requete si ce n'est plus.

merci j'ai changé mysql_real_escape_string par real_escape_string

Par contre si je rajoute les filtres et les requêtes réparées de doit toujours mettre les noms de mes post ou get.

Ce que je veux c'est que sa nettoie automatiquement les post ou les get

[Benjamin Delespierre]

Ce que je veux c'est que sa nettoie automatiquement les post ou les get

L'automatisation c'est à fuir en programmation ! Au bout d'un moment, ton programme devient une entité presque vivante, lors qu'il tourne plus personne ne sait ni comment ni pourquoi les données bougent et quand il faut tout démêler c'est un cauchemars. Une politique de sécurité digne de ce nom est spécifique et isolée.

[sinifer]

Justement j'ai l'impression qu'avec ces fonctions si il y a un problème on sait directement ou aller.

et sa protège des injection sql et xss.

désolé j'ai pas compris ce que tu veux dire par:

Une politique de sécurité digne de ce nom est spécifique et isolée

[Benjamin Delespierre]

ça veut dire que la politique de validation de données doit être encapsulée dans un composant indépendant du reste de l'application et injecté au besoin au niveau des contrôleurs.

Exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<?php
 
class MonController extends Controller {
 
    public function __construct (Validator $validator) {
        $this->_validator = $validator;
    }
 
    public function monAction ($a, $b, $c) {
        list($a,$b,$c) = $this->_validator->cleanup(compact('a','b','c'));
 
        // ...
    }
}

[Celira]

Tu sais que le champ 'numero' est censé contenir un nombre, donc tu vas appliquer un filtre de nombre dessus, le champ 'courriel' est censé contenir une adresse email, donc un filtre d'email, et ainsi de suite...

Si tu fais un gros filtre générique appliqué à tous les champs, tu vas de toute façon laisser passer plein de choses dedans pour qu'il fonctionne sur tout et ensuite repasser pleins de filtres spécifiques pour les détails. Autant faire directement des filtres spécifiques bien écrits.

Pour en revenir à tes fonctions, que se passera-il si tu dois afficher directement la valeur récupérée ? après passage dans escape_string, ça va être moche...
Et si jamais tu as un champ qui doit faire exactement 7 caractères, les caractères supplémentaires étant des espaces ? un coup de trim et pouf ! ça colle plus.
Et quid d'un éditeur WYSIWYG ? si tu retires tous les tags, tu perds toutes les balises et donc toute la mise en forme de l'éditeur.

Bref, mieux vaut gérer les choses au cas par cas.

[BPiero]

Et puis c'est pas en protégeant POST et GET que tu protèges toutes les entrées utilisateur... Ça pourrai aussi arriver par les cookies, le user-agent, l'adresse IP, le PUT et j'en oublie certainement. Mettons toi ou un autre dev reprend le site dans qques années, et ajoute du code pompé sur le net qui re-échappe, là c'est la merde le double échappement. Ou alors tu peux vouloir faire des calculs ou des traitement de chaînes sur les input avant insertion tu aura des surprises. Si tu souhaites utiliser des données provenant d'un serveur tiers tu auras aussi une faille.
C'est pourquoi il est conseillé de se protéger contre les injections SQL à la génération de la requête, et de se protéger du XSS à l'affichage.