Discussion :

[aspkiddy]

Bonjour,

J'ai un formulaire en PHP... Je vais le sécuriser maximum.
Pour empêcher les injections de code malicieux, j'utilise htmlspecialchars : ainsi, les informations remplies dans les champs par les utilisateurs qui contiennent de balises HTML seront sans code HTML actif.
Est-ce que c'est suffisant ? Sinon que je dois faire d'autres ?

Merci et bonne journée
Bonne année

[Benjamin Delespierre]

Sécurise les insertions en base avec htmlspecialchar ou strip_tags et mysql_real_escape_string ou les requêtes préparées.
Sécurise la récupération d'informations avec les filtres http://php.net/manual/fr/book.filter.php
Sécurise la sortie d'information avec les filtres également.

[amoiraud]

Salut,

Tu peut également utiliser mysql_real_escape_string pour éviter les injections SQL

[RunCodePhp]

Salut

Tout dépend du degré que tu souhaite obtenir, mais comme tu parles de "maximum", ne pas oublier le SSL (https).

Faire en sorte de générer un contenu HTML sécurisé c'est une chose, mais sans SSL les données transiteront "en clairs", donc elles peuvent toujours être interceptées voire modifiées en cours de route.

[grunk]

Je pense que c'est plus une question de philosophie mais je suis plus pour échapper les données à l'affichage et pas à l'insertion.
A l'insertion je filtre et protège des injections.

C'est un peu plus gourmand en ressource car on échappe les données pour chaque utilisateur au lieu de le faire une fois à l'insertion, mais du coup c'est une protection "active" qui va échapper même des données ne venant pas de la bdd.

Certain moteur de template ont d'ailleurs par défaut un échappement des données activé.

Il faut également te protéger de ce que l'on appelle les failles CSRF (cross site request forgery ) qui consiste à venir attaquer une partie du site (un formualire dans ton cas) avec un autre site. Voici : http://fr.wikipedia.org/wiki/Cross-site_request_forgery pour plus de détail

[aspkiddy]

Bonjour Benjamin Delespierre, amoiraud, RunCodePhp et grunk,

Je vais appliquer vos conseils étape par étape dans un formulaire fictif...
Alors, voici la 1re serrure (1re étape) avec htmlspecialchars :

Sécurise les insertions en base avec htmlspecialchar ou strip_tags et mysql_real_escape_string ou les requêtes préparées.
Sécurise la récupération d'informations avec les filtres http://php.net/manual/fr/book.filter.php
Sécurise la sortie d'information avec les filtres également.

dans mon formulaire :

Code :

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

1
2
3
<form method="post" action="engregistrement.php">
<input name="prenom" type="text" id="prenom" />
</form>

dans mon 2e fichier (engregistrement.php)

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
<?php
include"bd_db/connec.php";
include"select.php";
 
$prenom=$_POST["prenom"];
 
//  Pour traiter les accents et suprimer les code html :
 
$prenom= htmlspecialchars($prenom, ENT_QUOTES);
 
 
$query = "INSERT INTO $table_db (colone_prenom)";
$query .= "VALUES (''$prenom')";
 
$result = mysql_query($var_query, $cnx) or die (mysql_error());
 
?>

L'utilisateur entre, par exemple [<strong>toto] comme prénom
alors avec le code ci-dessus, j'obtiens l'enregistrement dans mon bd*: [&lt;strong&gt;toto]
et je peux visionner cet enregistrement dans un autre fichier PPP (dans le code ci-dessous) comme cela*: (dans le code source : [&lt;strong&gt;toto] et l'affichage (interprétation de navigateur) : [<strong>toto]

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
<?php
include"bd_db/connec.php";
include"select.php";
 
$req=  " select colone_prenom FROM $table_db  ";
$rep =  mysql_query($req, $cnx) or die( mysql_error() ) ;
while($row=mysql_fetch_row($rep)){
$prenom_engregistre=$row[0];
echo "$prenom_engregistre" ;
echo "\n";
echo " ; ";}
?>

Est-ce que cette procédure est correcte avec htmlspecialchars AU PREMIERE ÉTAPE?
Est-ce que cette procédure par htmlspecialchars est suffisante au niveau de sécurité AU PREMIERE ÉTAPE?

[Benjamin Delespierre]

Mes commentaire dans le code:

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
<?php
// bd db ? généralement fait /config/db/connection.php mais bon
include "bd_db/connec.php";
 
// kézako ?
include "select.php";
 
// Utiliser filter_input à la place
$prenom=$_POST["prenom"];
 
// strip_slashes + strip_tags + mysql_real_escape_string c'est mieux
$prenom= htmlspecialchars($prenom, ENT_QUOTES);
 
// Aucune sécurité contre les injections
$query = "INSERT INTO $table_db (colone_prenom)";
$query .= "VALUES (''$prenom')";
 
// or die en DEV mais JAMAIS EN PROD et surtout pas avec l'erreur MySQL retournée 
$result = mysql_query($var_query, $cnx) or die (mysql_error());

Est-ce que cette procédure est correcte avec htmlspecialchars AU PREMIERE ÉTAPE?
Est-ce que cette procédure par htmlspecialchars est suffisante au niveau de sécurité AU PREMIERE ÉTAPE?

Elle est correcte en ce sens qu'elle fait son job, en revanche, elle est clairement insécurisée.

[aspkiddy]

Bonjour Benjamin,

Super merci pour tes commentaire...

Mes commentaire dans le code....)
(...) en revanche, elle est clairement insécurisée.

voila je suis au 2e étape :

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
<?php
//connection au serveur
include"/config/db/connection.php";
	//sélection de la base de données et table
include"/config/db/selection.php";
 
// Utiliser filter_input à la place
								//$prenom=$_POST["prenom"];
$prenom = filter_input(INPUT_POST, 'prenom', FILTER_SANITIZE_STRING); //// voir les filtres http://www.php.net/manual/fr/filter.filters.php [Filtres de nettoyage]
 
// strip_slashes + strip_tags + mysql_real_escape_string c'est mieux
								//$prenom= htmlspecialchars($prenom, ENT_QUOTES);//  Pour traiter les accents et suprimer les code html :
$prenom= stripslashes($prenom); //Supprime les antislashs d'une chaîne et aussi les balises (exemple <strong>)
$prenom = strip_tags($prenom); // Supprime les balises (code)
 
$prenom = mysql_real_escape_string($prenom); //évite les injections SQL en protègeant les caractères spéciaux d'une commande SQL
 
$query = "INSERT INTO $table_db (colone_prenom)";
$query .= "VALUES ('$prenom')";
 
$result = mysql_query($query, $cnx) or die (mysql_error());
 
?>

Est-ce que cette procédure est correcte et suffisante AU 2. ÉTAPE?

[rawsrc]

Bonsoir,

Sécurise les insertions en base avec htmlspecialchar ou strip_tags et mysql_real_escape_string ou les requêtes préparées.

Je pense que c'est plus une question de philosophie mais je suis plus pour échapper les données à l'affichage et pas à l'insertion.
A l'insertion je filtre et protège des injections.

Je pencherai très clairement du côté de grunk. Pour la bonne raison que les données peuvent très bien être exploitées par d'autres programmes totalement étrangers au monde web et/ou PHP. J'ai eu une très mauvaise expérience sur un développement avec des données qui avaient été échappées ainsi à l'insertion (tout avait été échappé avec htmlentities()). Je déconseille donc fortement de mélanger de la présentation avec des données brutes. Une donnée brute doit rester brute, après c'est au développeur de bien saisir le sens qu'elle prendra dans un environnement donné et c'est encore à lui de s'en prémunir si nécessaire. Comme disait ma grand-mère, il n'est jamais bon de mélanger des torchons et des serviettes. Merci mémé...

[ABCIWEB]

Attention quand même de n'utiliser strip_tags qu'en connaissance de cause car cela limite les possibilités d'expression dans le formulaire (on ne pourra pas par exemple donner des exemples de code html ou php puisque les balises seront supprimées).

Comme grunk je déconseille l'utilisation de htmlspecialchars pour l'enregistrement en Bdd car sans parler de philosophie il y a des inconvénients pratiques : alourdi les tables avec des caractères inutiles et rend les données moins propres en cas d'exportation des tables sans traitement complémentaire.
Ces inconvénients sont relativement limités avec htmlspecialchars. Le pire serait d'utiliser htmlentities car en plus d'accroitre considérablement les inconvénients ci-dessus, cela rendrait impossible des recherches insensibles aux caractères accentués (je veux dire qu'une recherche sur 'a' ne pourrait jamais trouver 'à').

Je réserve donc pour ma part ces fonctions uniquement pour l'affichage.

EDIT : A bah tiens, le temps de poster je vois que rawsrc a déjà développé à peu près les mêmes arguments

[Benjamin Delespierre]

Gaffe quand même, on a vite fait d'oublier d’échapper les données en sortie, c'est pour ça que je les nettoies toujours en entrée.

[aspkiddy]

Bonjour tout le monde ,
Super merci les boys...

(...) (tout avait été échappé avec htmlentities()). Je déconseille donc fortement de mélanger de la présentation avec des données brutes.
(...)

(...)je déconseille l'utilisation de htmlspecialchars pour l'enregistrement en Bdd car sans parler de philosophie il y a des inconvénients pratiques
(...)

Je pense que c'est plus une question de philosophie mais je suis plus pour échapper les données à l'affichage et pas à l'insertion.
A l'insertion je filtre et protège des injections.
(...)

Alors, je n'utilise plus htmlentities() à l'insertion puisqu'il ne faut pas "mélanger la présentation avec des données brutes" comme rawsrc a dit et je n'utilise non plus htmlspecialchars pour l'enregistrement en Bdd à cause des inconvénients pratiques comme ABCIWEB a dit.

Gaffe quand même, on a vite fait d'oublier d’échapper les données en sortie, c'est pour ça que je les nettoies toujours en entrée.

Alors donc je vais systématiquement nettoyer en entrée (avec les filtres, INPUT_POST + stripslashes + strip_tags et mysql_real_escape_string).
Alors pour sécuriser les données en sortie, faut-il utiliser mysql_real_escape_string ?

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
<?php
 
// afficahge les accents
header('Content-Type: text/html; charset=UTF-8');
 
//connection au serveur
include"/config/db/connection.php";
//sélection de la base de données et table
include"/config/db/selection.php";
 
$req=  " select colone_prenom FROM $table_db  ";
$rep =  mysql_query($req, $cnx) or die( mysql_error() ) ;
while($row=mysql_fetch_row($rep))
	{
 
	//$prenom_engregistre=$row[0];  // desactivée  pour échapper les données à l'affichage en ajoutnat la ligne suivante avec  mysql_real_escape_string 
	$prenom_engregistre = mysql_real_escape_string($row[0]);
 
	echo "$prenom_engregistre" ;
	echo "\n";
	echo " ; ";
 
	}	
 ?>

Est-ce que cette procédure est correcte et suffisante à l'affichage de données AU 2. ÉTAPE?

[grunk]

Lit donc un peu les doc des fonctions dont on parle.

mysql_real_escape_stringdoit s'utiliser avant une requête pas sur le resultat de celle ci.

Pour faire simple :

Code :

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

1
2
3
<form method="post">
	<input type="text" name="nom" />
</form>

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
 
<?php
//Connexion BDD
//...
 
//Récupération donnée
//Filtrage
$nom = filter_input(INPUT_POST,'nom', FILTER_SANITIZE_STRING); // Changer FILTER_SANITIZE_STRING en fonction du besoin
//Protection injection sql
$nom = mysql_real_escape_string($nom);
 
//Insertion BDD
//...
 
//Autre partie du code affichant la données entrée
// SELECT nom FROm ma table
//Protection XSS
echo htmlentities($data['nom'],ENT_QUOTES);
?>

Avec ça t'es déjà pas mal tranquille. Après on peut encore améliorer avec les requête préparée , des token d'authentification unique par formulaire, etc ...

[ABCIWEB]

Oui donc y'a des fonctions spécifiques pour protéger les requêtes :
"mysql_real_escape_string" pour mysql ou "mysqli_real_escape_string" pour mysqli
ou
"quote" ou des requêtes préparées avec pdo

Et des fonctions spécifiques pour protéger l'affichage :
htmlentities ou htmlspecialchars


Si tu confonds les deux c'est parce que dans de nombreux exemples, certains utilisent également des fonctions de protection pour l'affichage pour traiter les données avant de les enregistrer en bdd. L'avantage évident est décrit par Benjamin Delespierre : t'as pas de risque d'oublier la protection dans ton code d'affichage.

Néanmoins ce confort et cette facilité n'est pas sans inconvénient et c'est ce dont nous parlions plus haut. Il est plus correct de ne pas mélanger les deux car cela procure une meilleure optimisation/utilisation des tables. En contre partie il faudra faire attention de ne pas oublier la protection dans ton code d'affichage.

[manticore]

Je suis pas vraiment d'accord avec nos amis, pour moi il faut de base échapper les données. C'est le principe de précaution en profondeur, si je me souvient bien d'une formation de l'OWASP, ils conseillent d'échapper les données à chaque entré et sortie, même entre partie truster.

https://www.owasp.org/index.php/Cate..._Guide_Project

Évidemment cela peut représenter certains inconvénient que vous avez déjà présenté.

Par contre :
- Lourdeur, c'est pas les quelques slashs en plus qui vont ralentir ta base de données

Mais cela présente l'énorme avantage d'éviter un oublie de traitement, ce qui est particulièrement vrai lorsque plusieurs travaillent en collaboration.

[RunCodePhp]

Je suis pas vraiment d'accord avec nos amis, pour moi il faut de base échapper les données. C'est le principe de précaution en profondeur, si je me souvient bien d'une formation de l'OWASP, ils conseillent d'échapper les données à chaque entré et sortie, même entre partie truster.

Il y a très longtemps de ça les développeurs de Php avaient eu la bonne mauvaises idées de créer cette directive magic_quotes_gpc.
A savoir que cette directive existe toujours par conséquent ça peu ce faire encore.

Mauvaise idée car cela a déboucher sur une quantité d'erreurs d’appréciations de celle ci ce qui à déboucher sur d’innombrables bugs, et ça même dans des projets très évolués (donc des codeurs expérimentés).

Mais pire, cela a favoriser de véhiculer l'idée que les données étaient protégées, ce qui pour beaucoup ne faisaient pas (ou plus) grand chose sur la vérifications des données extérieurs tels que GET POST entre autre.
Pleins de sites se sont fait piratés à cause de ça.


Depuis pas mal d'années, des années je dis bien, la communauté de Php a reconnue que c'était une mauvaise idée, et incite depuis à désactiver cette directive (la mettre à Off), puis inciter d'échapper les données uniquement au moment où cela est nécessaire.
Par ailleurs il est dit aussi qu'au niveau de la Base De donnée, l'échappement doit être fait par la base de donnée avec la méthode dédiée, et non par Php (comme addslashes).

Depuis quelque temps, la communauté à annoncée que cette directive sera définitivement supprimer (Php6 apparemment).


Si à ce niveau là il dit qu'il ne plus échapper systématiquement les données extérieurs, qu'il faut le faire juste là où c'est nécessaire et avec la méthode appropriée, il me semble qu'on peu leur faire confiances.
Pourquoi donc véhiculer encore et encore ce genre d'idées ?

Mais cela présente l'énorme avantage d'éviter un oublie de traitement, ce qui est particulièrement vrai lorsque plusieurs travaillent en collaboration.

Ca va autant favoriser l'oubli de supprimer ces échappements systématiques lorsque que cela n'est pas nécessaire, ce qui provoquera des bugs, ce qui peut provoquer d'énormes pertes de temps.
Sans compter qu'il sera difficile voir impossible d'utiliser la méthode d'échappement appropriée selon le contexte.
Ca en devient absurde.


On échappe une données QUE si c'est nécessaire, c'est largement plus simple, d'autant plus qu'avec PDO + requête préparée (pour exemple) ça le fait automatiquement, sans compter que ça le fait beaucoup mieux car adapté.


A savoir que, ce que fait cette directive magic_quotes_gpc si elle est à on ou un addslashes n'est pas du tout équivalent à ce que fait PDO et mysql_real_escape_string().


Mais encore, si on observe les Soft Open sources de nos jours (genre FrameWork, CMS, etc ... plus ou moins évolués), il font tout l'inverses.
C'est à dire que si la directive "magic_quotes_gpc" est à On (activée), ils suppriment systématiquement les quotes (stripslashes).
Ce qui au bout obligera d'échapper lorsque cela est nécessaire, et avec la bonne méthode.



Bref ... c'est une erreur à mon sens de rependre encore ce genre d'idées de nos jours.

[aspkiddy]

Bonjour,

Il y a quelque chose que je ne comprends pas : puisque je fais un enregistrement propre (filtrage, échappement du code, protection injection SQL, etc.) dans mon BDD, pourquoi dois-je utiliser une autre fonction pour l'affichage de cet enregistrement qui est propre ?

Utiliser htmlspecialchars() ou htmlentities(), c'est pratique pour éviter des données directement fournies par les utilisateurs . Mais moi, je les prends par intermédiaire de mon BDD...
Et si je dois utiliser htmlspecialchars() ou htmlentities() à l'affichage de données, je peux avoir des mauvaises surprises :

Exemple : Utilisateur entre dans input : [Je m'appelle André]
je les enregistre dans ma BDD : [Je m& # 39;appelle André]
Lorsque je l'affiche dans un autre écran : [Je m'appelle Andrà ©]
ou : [Je m& # 39;appelle Andr à ©] ou bien [Je m& # 39;appelle André]
Même si j'utilise :

Code :

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

header('Content-Type: text/html; charset=UTF-8');

ou

Code :

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

header('Content-Type: text/html; charset=iso-8859-15');

ou

Code :

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

header('Content-Type: text/html; charset=iso-8859-1');

avec toutes les possibilités :

Code :

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

$prenom_engregistre= htmlspecialchars($row[0], ENT_QUOTES);

ou

Code :

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

$prenom_engregistre= htmlspecialchars($row[0]);

ou

Code :

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

$prenom_engregistre= htmlentities($row[0], ENT_QUOTES);

ou

Code :

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

$prenom_engregistre= htmlentities($row[0]);

ou

Code :

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

$prenom_engregistre= htmlentities($row[0], ENT_SUBSTITUTE);

ou

Code :

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

$prenom_engregistre= htmlentities($row[0], ENT_DISALLOWED);

Que vous dites dans ce cas là ?

[ABCIWEB]

Utilises de préférence htmlspecialchars() plutôt que htmlentities().
D'une part c'est suffisant et d'autre part si tu travaille en utf-8 il n'est pas indispensable d'indiquer le charset comme paramètre dans la fonction avec htmlspecialchars alors que c'est indispensable avec htmlentities() (tant que php est par défaut en iso)

Faut pas mettre n'importe quel header pour indiquer le charset, faut mettre celui qui correspond à l'encodage que tu utilises. La norme actuelle est plutôt de travailler en utf-8 mais dans ce cas il faut ajouter une requête mysql avant de récupérer tes données pour indiquer à la bdd que tu travailles en utf-8. Il faut que tout ton code soit cohérent concernant l'encodage y compris la configuration de ton outil de travail. Si tu as besoin d'informations complémentaires sur l'encodage utf-8, google te donnera de bonnes réponses en rentrant "tuto utf-8".

Les fonctions qui protègent les chaines de caractères à l'entrée en bdd sont de nature différentes de celles qui protègent l'affichage et elles ne protègent pas des mêmes problèmes :
mysql_real_escape_string (and co) c'est pour protéger des injections sql, quant à htmlspecialchars (and co) c'est pour éviter que l'on puisse par exemple injecter du code javascript dans ta page ex: echo '<script type="text/javascript">code js</script>' directement ou par l'intermédiaire d'une bdd.

[aspkiddy]

Bonjour tout le monde et bonne semaine,

Utilises de préférence htmlspecialchars() plutôt que htmlentities().
(...)
Faut pas mettre n'importe quel header pour indiquer le charset, faut mettre celui qui correspond à l'encodage que tu utilises. (...)

Dans mon formulaire où on remplit l'input (nom) j'ai deux header*:

Code :

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

1
2
3
4
5
6
7
<?php
header('Content-Type: text/html; charset=UTF-8');
 ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

L'utilisateur rempli*: je m'appelle André

dans mon deuxième fichier où je mets cette information dans la BDD, il y a mon header*:

Code :

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

header('Content-Type: text/html; charset=UTF-8');

ma table est aussi*: avec interclassement*: [utf8_general_ci]

Donc dans ma table l'enregistrement c'est comme cela*: Je m& # 39;appelle (sans espace & # 39;!!!!)

Alors mon fichier qui affiche les données de mon BDD a aussi header('Content-Type: text/html; charset=UTF-8');

Donc il y a toujours le même header et c'est UTF-8

avec htmlspecialchars [$prenom_engregistre= htmlspecialchars($row[0], ENT_QUOTES);] j'arrive afficher "Je m& # 39;appelle André" au lieu de "Je m'appelle André"
C'est normal parce que l'on utilise "htmlspecialcahrs" pour convertit les caractères spéciaux comme ['] ou ["]...

Alors dans ce cas-là, comment je peux convertir [& # 39;](sans espace & # 39;!!!!) en ['] pour arriver au bon affichage : Je m'appelle André

[rawsrc]

Il y a quelque chose que je ne comprends pas : puisque je fais un enregistrement propre (filtrage, échappement du code, protection injection SQL, etc.) dans mon BDD, pourquoi dois-je utiliser une autre fonction pour l'affichage de cet enregistrement qui est propre ?

La donnée est "propre" toujours par rapport à un environnement spécifique. Quand tu utilises mysql_real_escape_string() ta valeur est "propre" dans le monde mysql. Tu n'as absolument aucune certitude pour pouvoir la considérer comme "propre" dans le monde navigateur ou dans un autre moteur de base de données. C'est pareil pour htmlspecialchars() ou htmlentities() qui t'assurent la proprété de ta valeur dans le monde navigateur mais tu n'as aucune assurance quant à sa "propreté" dans le monde base de données. A chaque niveau tu as généralement à ta disposition des nettoyeurs qui annihilent la dangerosité d'une valeur au sens global.

Voici ce que j'ai dit plus haut :

Une donnée brute doit rester brute, après c'est au développeur de bien saisir le sens qu'elle prendra dans un environnement donné et c'est encore à lui de s'en prémunir si nécessaire.