Discussion :

[hugodu28]

bonjour,

je viens de lire plusieurs articles sur le controle de données "POSTées" et je n'arrive pas trop à faire le point.

Une chose est acquise, c'est qu'il ne faut jamais faire confiance à l'utilisateur ni à la base de données.

dans les articles, je distingue donc 2 types de contrôles:
-ceux visant à éviter l'injection sql:
avec Htmlspecialchars() htmlentities()et mysql_real_escape string().

-ceux visant à contrôler que la variable correspond à un type de donnée
ctype_digit() ou _alnum() ou _alpha()ou controle de la longueur de chaine
strlen().

Est-ce que le premier type de controle doit etre systèmatique, car si j'attends une valeur numérique et si j'ai une variable ressemblant à <injection sql>, en passant par le filtre ctype_digit(), ça va obligatoirement être refoulé???
Sinon, je n'ai pas trouvé le contrôle pour déterminer si ma variable correspond à une date.

[sabotage]

htmlspecialchars() et htmlentities() servent à afficher du texte dans un page HTML sans risquer de rompre une chaine ou d'avoir des balises ou du code malveillant.

Pour mysql_real_escape string(), l'extension mysql_ est obsolète. On le remplacera avantageusement par PDO avec lequel les problèmes d'injection sont traités par la mécanique de préparation des requêtes.

Quand on attends une valeur numérique, effectivement le contrôle est simple à faire. Mais quand on demande à l'utilisateur de saisir du texte, on ne peut plus présumer de ce qu'il a saisi.

Pour valider une date, on peut la faire interpréter par PHP :

Code :

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

1
2
3
4
$date = DateTime::createFromFormat('j/m/Y', $_POST['date']);
if (!$date) {
   // la date n'est pas bonne
}

[hugodu28]

donc si j'ai bien compris,

quand je reçoit une variable $VAR,

je test si elle est au format attendu (ce qui me donne $VAR_test_ok)
puis j'introduit ma variable obtenue dans ma requete PDO

prepare(SELECT* from tableX WHERE nom=:user);
execute(:user=$VAR_test_ok)

La synthaxe est mauvaise mais c'est l'idée du cheminement.


Après, c'est dans la VUE (pour MVC) qu'il faudra utiliser htmlspecialchars() et htmlentities() pour afficher la valeur des variables???

Code :

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

1
2
3
4
 
// j'obtiens une variable $VAR_nom suite à requete select dans ma bdd
 
echo htmlentities($VAR_nom);

[hugodu28]

bonjour,
je souhaite tester une variable de type numérique et qui peut avoir pour valeur 0 ou 1.

Est-ce que mon code est bon où il y a-t-il une façon plus propre de faire.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
$TEST= valeur à tester;
 
if(ctype_digite($TEST) AND ($TEST=0 or $TEST=1))
     {
     echo "valeur numérique";
     }
     else
     {
     echo"mauvais type donnée";
     }

[sabotage]

Peut être plus simplement :

Code :

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

if($TEST === 0 OR $TEST === 1)

[hugodu28]

J'ai essayé ce code mais ça me mets un maxi message d'erreur
call to undefinet method DateTime::createFromFormat

Pour valider une date, on peut la faire interpréter par PHP :

Code :

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

1
2
3
4
$date = DateTime::createFromFormat('j/m/Y', $_POST['date']);
if (!$date) {
   // la date n'est pas bonne
}

[/QUOTE]

Sinon, pouvez-vous m'expliquer une petite chose.

On utilise bien htmlentities pour ôter les signes particuliers d'une variables,
notament celles venant de la BDD.
Ce qui implique, que le pirate a eu accès au mot de passe et identifiant de la bdd et qu'il a changé des données ou la structure des tables?

[sabotage]

createFromFormat n'existe qu'a partir de PHP5.3

On utilise bien htmlentities pour ôter les signes particuliers d'une variables,

Ca ne les enlève pas, ça les transforme en entité HTML.
Imaginons que quelqu'un saisisse la chaine

Code :

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

<script language="JavaScript">alert('hello');</script>

passée dans htmlentities, on aura

Code :

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

& lt;script language=& quot;Javascript& quot;& gt;alert(& apos;hello& apos;);& lt;/script& gt;

La navigateur affichera bien < et > mais ne les considérera pas comme des ouvertures de tags.

Autre exemple cette fois ci sans mauvaise intention :
Un utilisateur a saisi dans un champs : je m'appelle "jack"
tu veux afficher sa saisie dans un champs input :

Code :

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

<input type="text" value="je m'appelle "jack"" />

boudaboum le code HTML est en vrac a cause des guillemets.
avec htmlentitiers :

Code :

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

<input type="text" value="je m'appelle & quot;jack& quot;" />

[hugodu28]

ok merci

sinon, on est bien d'accord que le fait de vérifier les valeurs issues de la base de donnée, c'est uniquement si on s'est fait cracker sa BDD?

Car les requetes PDO ne permettent pas de falsifier les données de la BDD
exemple mettre du texte dans un champs numerique

[sabotage]

Dans mes deux exemples il n'y a pas eu de hack de la base de données : l'utilisateur a seulement saisi des données librement là ou on le lui demandait.

Les requêtes préparées avec arguments nommées empechent les injections SQL, c'est à dire le détournement d'une requête existante par l'introduction de commandes SQL dans des paramètres saisies.
Mais ce que l'utilisateur saisi se retrouvera dans la base données.

Par contre tu ne peux pas, même si tu le voulais, mettre du texte dans une colonne numérique.