[Sécurité] Sécurité de connection

**psychoBob** · 22/01/2006, 23h41

Veni Vidi Vici 8)

Sinon un gars chez OVH m'avait dit que le seul moyen d'assurer une sécurisation totale des formulaires, c'est de controler la nature des informations entrées dans les champs, au moyen des expressions régulières.

**vg33** · 22/01/2006, 23h44

Envoyé par psychoBob

Si je fais ça avant l'insertion dans la base, t'es ko ?

Code :

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

1
2
3
 
$contenu= htmlentities($_POST['$contenu']);
$contenu= mysql_real_espace_string ($contenu).

Oui, je pense. Mais suis avant le conseil de MrN pour contrer le magic_quotes (sinon, tu risques de doubler les \, non ?)

**vg33** · 22/01/2006, 23h47

Envoyé par psychoBob

Sinon un gars chez OVH m'avait dit que le seul moyen d'assurer une sécurisation totale des formulaires, c'est de controler la nature des informations entrées dans les champs, au moyen des expressions régulières.

Les expressions régulières (très lourdes en termes de performances) ne sont utiles que si tu cherches un motif précis (courriel, code postal...). Si tu acceptes un texte normal, tu dois pouvoir laisser passer tout caractère, à condition de supprimer leur danger éventuel (=> htmlentities() et mysql_real_escape_string()).

**psychoBob** · 22/01/2006, 23h48

j'ai essayé, comme j'ai marqué au dessus, ça ne double rien, ça fait pareil qu'avec htmlentities. Mais bon peut être que dans certains cas de figure, c'est mieux d'utiliser ces deux fonctions consécutivement.

**psychoBob** · 22/01/2006, 23h55

Admettons que le problème de l'insertion dans la base soit réglé en utilisant l'une après l'autre les deux fonctions susnommées.

Mais quand on fait cela :

==> Inscription de données dans un formulaire
==> Rechargement de la page en appuyant sur "valider"
==> Affichage du contenu du formulaire avant l'envoi définitif dans la base.

Ici on envoi tout de même des données au serveur, à défaut de les envoyer dans la base.

Je fais cela :

Code :

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

1
2
$form=htmlentities('$_POST['form'])
$form=stripslashes($form) // on stripslashes pour afficher la prévisualisation du message sans les slashes devant les quotes.

Y a t'il une faille là dedans ?

**vg33** · 23/01/2006, 00h02

Je pense que c'est bon.
En effet, le risque en réaffichant des données est l'attaque XSS, qui suppose l'utilisation des balises html... justement traduites par htmlentities().

**Mr N.** · 23/01/2006, 00h07

D'autant plus sécurisé que, dans ce cas précis, les données viennent de post, et c'est légèrement difficile de convaincre un utilisateur de cliquer sur une url qui enverra une requete post (url = get). mais bon, on est jamais trop prudent.

**Kioob** · 23/01/2006, 09h55

Si tu fais un htmlentities avant l'insertion en base de données, non seulement cela ne t'apporte absoluement rien coté sécurité, mais en plus ta base de données devient inutilisable pour autre chose que de l'affichage HTML : impossible de faire une recherche dans la base puisque tout le contenu est "encodé" en HTML, impossible de bénéficier de "l'intelligence" de MySQL qui fait le rapprochement "majuscules / minuscules / accents", etc. Et pour peu que tu veuilles sortir des données sous un autre format qu'HTML, tu es coincé... Bref, la base est corrompue, en cas de modif du site il faudra tout refaire.

**vg33** · 23/01/2006, 10h09

Tu conseilles donc de faire un htmlentities() uniquement avant l'affichage ?

**Kioob** · 23/01/2006, 10h40

Oui. Et pour être exact je me contente même d'un htmlspecialchars(), et je mets l'entete qui va bien au début du document pour la gestion des accents.

**psychoBob** · 23/01/2006, 12h21

Si tu fais un htmlentities avant l'insertion en base de données, non seulement cela ne t'apporte absoluement rien coté sécurité, mais en plus ta base de données devient inutilisable pour autre chose que de l'affichage HTML : impossible de faire une recherche dans la base puisque tout le contenu est "encodé" en HTML, impossible de bénéficier de "l'intelligence" de MySQL qui fait le rapprochement "majuscules / minuscules / accents", etc. Et pour peu que tu veuilles sortir des données sous un autre format qu'HTML, tu es coincé... Bref, la base est corrompue, en cas de modif du site il faudra tout refaire.

N'égaxérons rien, si tu filtres aussi par htmlentities la requête entrée dans le formulaire de recherche, tu te retrouves avec un mot encodé à aller chercher parmi des mots encodés : ça doit fonctionner.
On peut toujours réencoder les données en sortie, avant l'affichage.
Mais bon j'ai déjà lu qu'il vaut mieux stocker des données brutes dans la base de données.
Ceci dit je donne la priorité à la sécurité. Tu vas sans doute me dire que l'on peut assurer celle-ci sans htmlentities.
Avec striptags + mysql_real_escape_string par exemple ?

**Kioob** · 23/01/2006, 12h35

N'égaxérons rien, si tu filtres aussi par htmlentities la requête entrée dans le formulaire de recherche, tu te retrouves avec un mot encodé à aller chercher parmi des mots encodés : ça doit fonctionner.

Absolument pas. Un texte contenant par exemple le caractère "&" sortira lors d'une recherche sur le terme "amp" ; et ceci est vrai pour toutes les entitées HTML.
De la même façon, un texte contenant par exemple le mot "bébé" ne sortira pas lorsqu'un utilisateur fera une recherche sur le mot "bebe".

Bref : inexploitable correctement.

On peut toujours réencoder les données en sortie, avant l'affichage.

Faire un html_entity_decode() ? C'est effectivement une solution pour retrouver des données correctes... à condition d'avoir cette fonction sous la main... ce qui n'est pas le cas de toutes les versions de PHP, ni de tous les langages...

Ceci dit je donne la priorité à la sécurité. Tu vas sans doute me dire que l'on peut assurer celle-ci sans htmlentities.
Avec striptags + mysql_real_escape_string par exemple ?

Mais je ne vois même pas pourquoi tu penses que cela apporte un gain de sécurité ? MySQL n'est absoluement pas sensibles aux tags HTML, au code Javascript, etc. Il n'y a aucun rapport.

Pour stocker en base de données, il faut uniquement utiliser mysql_real_escape_string(). C'est tout, rien besoin d'autre.

Après effectivement si tu veux envoyer ces données en HTML, alors il faut t'adapter au format d'envoi, et donc ici utiliser htmlspecialchars() ou htmlentities(), comme bon te semble.
Mais ceci est également vrai pour un fichier CSV par exemple : tu ne vas "protéger" tous les points virgules de tes textes ni doubler les quotes dans ta base de données uniquement parce que tu es susceptible de faire un export CSV... Et quid des fichiers PDF, XML, voir même les images ?

**psychoBob** · 23/01/2006, 12h47

Mais je ne vois même pas pourquoi tu penses que cela apporte un gain de sécurité ? MySQL n'est absoluement pas sensibles aux tags HTML, au code Javascript, etc. Il n'y a aucun rapport.

Je pensais que si, mais effectivement, cela change bien des choses, comment en être certain (source) ?
J'ai souvent lu qu'il faut se préserver de l'envoi de code dans la base, qui est donc inséré dans des balises javascript ou autres.

Sinon par exemple dans ma base de données encodée, il est toujours possible de réencoder le tout, que ce soit par htmlentitites, str_replace ou autre, c'est tout de même un problème secondaire. Pour les recherches c'est effectivement un problème. Mais j'utilise googlesearch...

En fait j'ai commencé à programmer il y a six mois, et sur un forum où j'avais demandé "comment sécuriser les formulaires", on m'avait répondu "à grand coup de htmlentities" et le gars semblait s'y connaître.

ça a quand même un avantage les données précodés dans la base : plus besoin de transformer les "é" en "é" avant l'affichage, on gagne du temps, ils sont transformés avant l'insertion dans la base.
Je sais je sais on va me dire que c'est infime comme temps gagné et qu'une base doit stocker des données brutes pour servir à de multiples usages...
Mais c'est quand même du temps gagné.

**vg33** · 23/01/2006, 12h58

Le seul avantage à utiliser htmlentities() avant l'insertion en bdd, c'est... qu'on ne risque pas d'oublier de l'utiliser à l'extraction, avant l'affichage.
Alors, à mon avis, si tu es sûr de bien utiliser htmlentities() avant l'affichage, tu stockes des données brutes. Sinon, tu le fais avant insertion. Et tu pourras toujours pondre un script pour nettoyer la base (= extraire les champs, htmlentities_decode(), puis update).

**Mr N.** · 23/01/2006, 13h19

Envoyé par psychoBob

J'ai souvent lu qu'il faut se préserver de l'envoi de code dans la base, qui est donc inséré dans des balises javascript ou autres.

Tu confonds deux types d'injections qui n'ont rien à voir.
1. les injections sql
l'utilisateur rentre des caractères spéciaux dans un champ apparemment innocent (champ de recherche, login, offset de pagination, ...) afin de prendre le controle du serveur de base de données ou d'afficher/modifier des données sensibles (mot de passe de l'admin par exemple)
http://en.wikipedia.org/wiki/SQL_Injection
http://fr.wikipedia.org/wiki/Injection_SQL
http://php.net/security.database.sql-injection

2. les injections de codes javascripts ou attaques XSS
L'utilisateur fait en sorte d'insérer du code javascript dans la page d'un autre utilisateur, ce code étant soit stocké dans un message de forum par exemple, soit transmis par url et affiché directement par le script peu regardant. Tout ceci afin de voler des cookies ou d'inciter l'utilisateur à donner des informations sensibles en modifiant par js la page affichée.
http://en.wikipedia.org/wiki/XSS
http://fr.wikipedia.org/wiki/Cross_site_scripting

**psychoBob** · 23/01/2006, 13h24

je vais voir les liens que vous m'indiquez.

Vous êtes en train de me dire que pour le moment, puisque je filtre les données des formulaires par htmlentities(), je crois que ma base de données est protégée alors qu'elle ne l'est pas ?

Pourtant comme je l'ai montré un peu plus haut, mon morceau de code de type injection sql a été slashé de la même manière avec htmlentities qu'avec mysql_real_escape_string (ok, pour Mr N, peut être que dans certains cas, htmlentities est insuffisant, c'est noté, mais dans mon exemple les deux ont fait le même travail).

Donc ne me dites quand même pas qu'htmlentities n'a strictement aucun effet sur la sécurisation de la base !
Je vais lire les liens.

**Mr N.** · 23/01/2006, 13h32

Envoyé par psychoBob

Donc ne me dites quand même pas qu'htmlentities n'a strictement aucun effet sur la sécurisation de la base !

Pour la enieme fois : non, puisque ce n'est pas son rôle, elle n'est pas prévue pour ça.
Ca va rentrer oui ?

Et ton code de type injection sql n'en est pas un. Apparemment c'est un simple exemple. Il n'existe pas de code "type", puisqu'une injection sql marchera sur une requête et pas forcément sur une autre. Donc inutile de croire que si tu fais un vulgaire copier coller de ce machin dans tes champs ça testera ta vulnérabilité, bien au contraire apparemment puisque tu es persuadé (c'est le moins qu'on puisse dire) du contraire.

**psychoBob** · 23/01/2006, 13h37

Bon alors:

Pour le Xss ils disent :

Code :

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

1
2
3
4
5
6
7
 
Éviter la faille
 
Plusieurs méthodes sont possibles pour éviter le XSS
 
    * Encoder le HTML de sortie (htmlentitities() en PHP)
    * Valider les entrés uniquement le contenus autorisé venant d'un formulaire (Par exemple, un champ 'âge' ne devrais contenir que des chiffres)

Pour les injections sql, ils ne parle que de addslashes().

Si j'ai bien tout compris :
-On peut balancer tout le code html, php que l'on veut dans la base, la seule chose qui fera effet sur celle-ci sera une requête sql elle même.
Donc il suffit au moment de l'envoi de données dans la base d'ajouter des "/" devant les quotes. Mais on peut laisser entrer les <script>, <?php, <?xml et etc...
- En revanche, au moment de l'affichage, les éventuelles balises citées juste au dessus peuvent poser problème et il convient donc de les décoder par htmlentities.

ça c'est léger et ça suffit, si je vous suis.

Et si on veut faire un truc bien balaise du genre htmlentities + striptags+ mysqlreal_escape_string + addslashes + une fonction qui envoit un mail à Sarkozy en cas de requête sql dans le formulaire, le tout avant l'envoi de ce dernier dans la base (le formulaire, pas Sarkozy). Ca n'est quand même pas un peu plus sûr? hein? quand même un petit peu non ?

Autre question : on peut entrer une requête sql dans un champ de formulaire sans l'encadrer de <?php ?> (pour une page php) ? Parce que je partais de l'idée qu'une requête sql non encadré par ces balises ne peut pas fonctionner, d'où l'utilité d'htmlentities.

Donc inutile de croire que si tu fais un vulgaire copier coller de ce machin dans tes champs ça testera ta vulnérabilité, bien au contraire apparemment puisque tu es persuadé (c'est le moins qu'on puisse dire) du contraire

N'empêche qu'il a quand même été slashé

Donc : mysql_real_escape_string avant l'insertion dans la base et htmlentites avant l'affichage ?

**Mr N.** · 23/01/2006, 13h47

Envoyé par psychoBob

Donc il suffit au moment de l'envoi de données dans la base d'ajouter des "/" devant les quotes.

Ca dépend du moteur sql. Pour mysql, addslashes ne suffit pas, il faut la remplacer par mysql_real_escape_string.

Envoyé par psychoBob

Mais on peut laisser entrer les <script>, <?php, <?xml et etc...

oui. Mais <?php n'a rien avoir avec une injection XSS, puisque c'est sur le serveur que ça va se passer, lors d'un joli eval.

Envoyé par psychoBob

Et si on veut faire un truc bien balaise du genre htmlentities + striptags+ mysqlreal_escape_string + addslashes + une fonction qui envoit un mail à Sarkozy en cas de requête sql dans le formulaire, le tout avant l'envoi de ce dernier dans la base (le formulaire, pas Sarkozy). Ca n'est quand même pas un peu plus sûr? hein? quand même un petit peu non ?

Non ca ne change rien et ca complexifie les données stockées pour rien, comme l'a mieux expliqué Kioob.
Comme tu l'a compris, <script> sera exploitable à l'affichage chez le client. Donc tu dois protéger à ce moment là. Si tu n'as pas envie d'y faire à chaque fois par ce que tu trouves ça lourd, et bien tu utilises un cache, c'est fait pour ça. M'enfin là c'est pas bien grave, c'est juste que conceptuellement c'est le fouilli, et je n'aimerais pas passer derrière toi pour debugger ton code.

Sinon pas la peine de mettre toutes les fonctions de php qui te tombent sous la main. Un peu de jugeotte quand meme :
mysqlreal_escape_string = addslashes + autres choses
Donc pas la peine de faire ... + mysqlreal_escape_string + addslashes + ...