Enregistrements saisies sur table aléatoires

Bonjour,

Je me permets de vous écrire car je rencontre un soucis avec mon formulaire PHP.

J'ai créé un formulaire "classique" que j'envoie à des personnes.

Ces personnes répondent et leurs saisies sont stockées dans ma base SQL.

Cela fonctionne, mais pas pour tout le monde.

Je m'explique, certaines personnes répondent au formulaire: une nouvelle entrée dans ma table SQL se créée avec leurs réponses et le numéro ID associé sont stockées dans ma base. Ici, tout fonctionne.

D'autres personnes font la même chose est rien ne se créé. De leur côté, ils peuvent envoyer le questionnaire, tout se passe comme si cela avait correctement fonctionné.

Je pensais que cela pouvait peut être provenir d'une "sécurité" ou "protection" de leur PC ou réseau qui au final n'envoie pas leurs saisies, mais je ne sais pas si cela est possible, ou si c'est autre problème.

Est-ce que par hasard, vous auriez une piste que je pourrais creuser ?

Merci beaucoup et à bientôt

Bruno

Hello

Ton problème est-il reproductible ?
Quel est la correspondance entre les personnes ou le formulaire ne fonctionne pas ?
- Navigateur
- Extension
- Authentification

As tu des logs ?

Si rien ne ce crée ca vient forcément de ta requête sql, par exemple un champ non nullable ou tu lui passes une valeur null. De plus si les erreurs sont désactivées avec pdo ou myslqli c'est invisible.

Super merci Kévin pour ta réponse.

Alors, je te propose que je réponde à tes questions et je te donne les résultats que j'ai obtenu selon tes conseils.

Tout d'abord, étant chez Hostinger, j'ai activé les log (logErrors et displayErrors)

J'ai fait un test, j'ai rempli toutes les questions du formulaire et j'ai validé. Je n'ai pas eu de messages d'erreurs (log).


Je te détaille comment fonctionne le formulaire. Pour simplifier, je mets des [...] pour raccourcir le code afin qu'il rentre dans le sujet de discussion. Je prends l'exemple de ma première question:


Sur un fichier nommé formulaire.php (tout le formulaire est uniquement sur une seule page)

Code:

---

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

<form action="https:XXXXXXXXX/VDresultat.php" method="post" enctype="multipart/form-data" name="formSaisie1" target="_self" onSubmit="return soumissionOk(this)">   [...]   <table class="ma-table"> <tr> <td colspan="8"><h1>1- Profil</h1></td> </tr> <tr> <td colspan="8"><h2>Pourriez-vous nous indiquer, </h2></td> </tr> <tr> <td>le nom de votre structure</td> <td colspan="7"><input type="text" name="1" id="1"></td> </tr>   [...]   </table>   [...]   <center><input type="submit" style="width: 300px; height: 50px; font-size:30px;" name="Suivant" id="Suivant" value="Envoyer"></center>   [...]   </form>

---

Sur un fichier VDresultat.php, je récupére les saisies et je les envoie sur ma base

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

<?php include ('../script/connection.inc.php'); $s1=$_POST['1'];   [...]   $sql = "INSERT INTO `VDresultat` ( `id` ,`1` [...] ) VALUES ('', '".$s1."')"; [...]   if (mysqli_query($conn, $sql)) { echo "Nouveau enregistrement créé avec succès"; } else { echo "Erreur : " . $sql . "<br>" . mysqli_error($conn);}   mysqli_close($conn); header("Location: ../merci.php");

---

Ma table de donnée nommée également VDresultat est comme ceci:

Code:

---

1 2 3 4 5 6 7 8 9

CREATE TABLE IF NOT EXISTS `VDresultat` ( `id` int(1) NOT NULL auto_increment, `1` varchar(300) collate latin1_general_ci NOT NULL default '',   [...]   PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci AUTO_INCREMENT=1 ;

---

Enfin, je renvoie vers un fichier merci.php

Mon problème est le suivant:

Certaines personnes saisissent leurs réponses sur le formulaire (j'ai fait aussi le test: répondre uniquement à quelques questions ou toutes questions, c'est le même résultat) et tout fonctionne normalement. Une ligne apparait dans ma table avec l'individu et ses réponses.

D'autres personnes font la même chose et la ligne ne se créée pas.

J'ai essayé avec les navigateurs: Brave, Chrome et Firefox, c'est le même résultat: parfois ça marche et d'autre non

Je n'arrive pas à voir où cela peut poser problème et où j'ai fait une erreur.

Est-ce que par hasard, tu aurais des pistes ?

Encore merci

Bruno

Le problème c'est que vous donnez des extraits de code, de définition de table mais rien n'est complet, dès lors il est difficile d'analyser votre code plus en profondeur pour comprendre où ça coince, ou même de le tester de notre côté.

Mais ce code me semble très ancien et peu robuste, quand je vois un truc comme ceci:

Code:

---

1 2	) VALUES ('', '".$s1."')";

---

ça sent l'injection SQL à plein nez. Non seulement c'est une faille de sécurité énorme mais ça peut expliquer que certaines requêtes échouent. Par exemple, si on entre une valeur contenant une apostrophe (single quote), alors le code SQL sera tronqué. Faites le test !
Il y a peut-être des warnings que vous ne voyez pas.

Forcez les erreurs, s'il le faut tenter de mettre à jour un champ qui n'existe pas dans votre table. Le but étant de faire apparaître clairement les erreurs quand elles se produisent. Il est conseille de les écrire dans un log et ne pas les afficher directement à l'écran. Non seulement c'est peu professionnel mais révéler la structure de votre DB peut aider un hacker éventuel à affiner ses attaques.

Le point que l'on puisse faire si on s'en tient à ce code "vieillot", c'est d'utiliser des requêtes paramétrées afin de résoudre ce problème d'injection SQL et de fiabiliser le traitement.

Je passe sur les conventions de nommage, un champ qui s'appelle 1 c'est pas super-intuitif...

Déjà bonjour binarygirl

Quel ton moralisateur et donneur de leçon. C'est un forum d'entraide pour tout public de tout niveau, l'agressivité est inutile, faites en l'expérience ça vous sera plus utile.

Dans vos commentaires, je vais quand même essayer de trouver quelque chose de positif en essayant quelques pistes.

Mais merci, c'était quand même agréable de discuter avec vous.

A bientôt

Le problème c'est que vous nous demandez de jouer à la devinette, d'abord vous ne postez pas de code, ensuite vous fournissez quelque chose de très incomplet et ce n'est pas un MRE.

Donc il faudrait du concret pour avancer et pour qu'on puisse vous aider efficacement.

En relisant votre code je vois encore ceci:

Code:

---

<form action="https:XXXXXXXXX/VDresultat.php" method="post" enctype="multipart/form-data" name="formSaisie1" target="_self" onSubmit="return soumissionOk(this)">

---

Il y a un bout de Javascript qui est exécuté lors de l'envoi du formulaire.
Peut-être que le problème vient de cette fonction qui échoue et empêche l'envoi du formulaire.
Mais on n'en sait rien puisqu'on n'a pas le code.

Hypothèse du moment: le problème vient des données. Je pense que le single quote (et d'autres caractères aussi) peut faire crasher votre code, et c'est facile à vérifier de votre côté. Si vous confirmez cela, alors il n'y a plus qu'à corriger et ce sera un problème en moins.

En 2023 les injections SQL ne devraient plus exister. Je pense que vous n'avez pas conscience des risques, n'importe qui peut exploiter une faille aussi basique avec des outils comme SQLmap. Non seulement votre site est hackable mais les données de votre DB peuvent se retrouver entre de mauvaises mains, ce qui ne fera pas plaisir à vos clients non plus. Il y va de votre responsabilité professionnelle.
Donc je me permets d'insister sur ce point: ne négligez pas la sécurité sinon vous vous en mordrez les doigts. Vous pourriez même vous prendre des amendes de la CNIL pour négligence.

Prenez cela comme une consultation gratuite chez le dentiste: il vous fait du mal pour que vous alliez mieux après.
Mais si vous ne lui dites pas clairement quelle dent vous fait mal, alors il devra peut-être taper à gauche et à droite et vous faire encore plus de mal...

Je rejoins BinaryGirl sur le SQL qui pose problème :

Code:

---

1 2 3 4 5 6 7

$sql = "INSERT INTO `VDresultat` ( `id` ,`1`   [...]   ) VALUES ('', '".$s1."')";

---

Ici il nous manque l'échappement de la valeur, si l'utilisateur saisit une ' la requête plante (au mieux).

=> Il faut échapper les valeurs SQL avec mysqli_real_escape_string()

Bonjour Binarygirl,

Oui, comme le dentiste peut utiliser une anesthésie pour soigner une dent sans avoir mal. Un ton moralisateur ne sert à rien, n'aide en rien. Prenez plutôt ma remarque comme une façon d'améliorer votre communication. J'apprécie plus votre dernier message, plus apaisé et qui surtout apporte réellement des pistes à explorer.

Du coup merci Binarygirl et Séb, je vais regarder les pistes que vous me dites. je n'y avais pas pensé.

De mon côté, j'ai refait un test également sur mon site et je me suis aperçu que lorsqu'un individu reste plusieurs minutes avec le formulaire ouvert sans le valider, puis le valider au bout, par exemple, de 20 minutes, mon problème apparaît. Je vais aussi chercher en ce sens aussi, on ne sait jamais.

Je reviendrai vers le forum pour partager les résultats.

A bientôt

Bonjour Séb

Merci pour le retour. Effectivement, vous avez raison je n'ai pas mis de mysqli_real_escape_string()

Je vais investiguer sur cela et je me permettrai de revenir pour poster le résultats. Ma démarche est que j'essaie de faire seul pour apprendre et quand je bloque je demande.

Encore merci et à bientôt

Citation:

---

De mon côté, j'ai refait un test également sur mon site et je me suis aperçu que lorsqu'un individu reste plusieurs minutes avec le formulaire ouvert sans le valider, puis le valider au bout, par exemple, de 20 minutes, mon problème apparaît.

---

Typiquement un problème de session / cookie qui expire et invalide le formulaire.

Génial ça marche !!!

Merci Séb, alors il y avait deux problèmes:

1) Problème session / cookie. J'ai vu avec la notice php et effectivement j'avais fait une erreur et j'ai corrigé, refait un test et ça fonctionne :)
2) Problème de htmlspecialchars et ENT_QUOTES. Dans l'extrait de code que j'avais donné plus haut:

Code:

---

$s1=$_POST['1'];

---

Il fallait écrire ceci:

Code:

---

$s1=htmlspecialchars($_POST['1'], ENT_QUOTES);

---

Je n'ai aucun mérite, le problème 2, on me l'a soufflé dans un autre forum sur php.

et là tout fonctionne

Merci beaucoup pour l'aide.

A bientôt

Bruno

Citation:

---

Il fallait écrire ceci:

Code:

---

$s1=htmlspecialchars($_POST['1'], ENT_QUOTES);

---

---

Surtout pas ! Il faut enregistrer les données dans leur forme la plus neutre possible.
Autrement quand tu devras sortir les données sous CSV, ou autre format, tu devras décoder le HTML :aie:
Sans oublier que tu devras échapper uniquement les autres caractères que ENT_QUOTES à l'affichage HTML courant (sous peine de double codage)
Bref, une très mauvaise solution...

Ici la seule bonne solution est d'échapper la valeur SQL avec la fonction faite pour => mysqli_real_escape_string()

Récap. :
1. Tu enregistres les données en entrée de base de données dans leur format brut et correctement échappée pour SQL
2. Tu les codes/échappes en sortie de base de données au besoin selon le format visé => htmlspecialchars() si HTML, fputcsv() si CSV, etc.

Citation:

---

Envoyé par Brunodurant42

Il fallait écrire ceci:

Code:

---

1 2	$s1=htmlspecialchars($_POST['1'], ENT_QUOTES);

---

---

Hum non. Cette fonction est typiquement utilisée pour convertir des caractères à afficher ou insérer dans le code HTML renvoyé à l'utilisateur, par exemple alimenter des listes déroulantes. Si un string contient des caractères comme < ou > alors ce serait converti en &lt; ou &gt; sinon ça déstructurerait le code HTML.

Pour dire les choses simplement: vous ne devriez pas transformer les valeurs que vous recevez de l'utilisateur.
Par contre, vous pouvez les valider et les rejeter si elles contiennent des éléments indésirables.
Et puis vous les insérez telles quelles dans la DB, de préférence avec des requêtes paramétrées.
Pour les afficher proprement, vous pouvez utiliser la fonction htmlspecialchars. J'ai bien dit les afficher, pas les convertir.

Mais on peut faire quelque chose de plus simple et plus propre en utilisant un template engine comme Twig, même si on ne veut pas utiliser un framework PHP complet tel que Symfony. Ça permet aussi de séparer le code HTML de la logique PHP et de rendre l'application plus souple.
D'ailleurs, si vous visitez le lien vers Twig il montre justement l'absurdité d'utiliser htmlspecialchars + ENT_QUOTES, surtout si vous allez répéter ça souvent.

Utiliser mysqli_real_escape_string seul n'est pas la solution ! Lisez notamment la doc et la section "Security: the default character set". C'est malheureusement moins simple qu'on le croît mais ce sont des méthodes surannées de toute façon.

Ne perdez pas votre temps à rafistoler du code en utilisant des techniques d'il y a 20 ans, faites des requêtes paramétrées et je suggère même d'utiliser PDO au moins.

Citation:

---

Envoyé par Brunodurant42

et là tout fonctionne

---

Pas si vite :)
Peut-être que "ça marche", dans le cas de figure précis que vous avez testé... mais je crois qu'en bonne partie vous avez juste déplacé le problème. Juste pour tester, une ligne de texte avec plein de caractères "spéciaux" ou des apostrophes, ça donne quoi à l'arrivée ? Toujours conforme à la valeur d'origine ?
Avant de crier victoire, testez votre code en lui fournissant des données un peu extrêmes.
Évidemment, si vous avez provisionné un varchar(300) pour une valeur précise, il convient aussi de vérifier que l'utilisateur n'a pas "tapé" davantage, sinon la valeur serait tronquée. Ce n'est pas non plus ce qu'on veut. En réalité 300 me paraît excessif, je dirais plutôt 50 et je rajouterais la même valeur dans un attribut maxlength pour le input type="text" correspondant, ce qui ne vous dispense pas de vérifier côté serveur la valeur reçue car un attaquant n'est pas soumis aux limitations d'un navigateur web.

D'accord, merci à vous deux.

J'ai refait un formulaire tout simple pour que je comprenne les solutions proposées.

La page du formulaire s'appelle testform.php

Code:

---

1 2 3 4 5 6 7 8 9 10 11

<form action="https:XXXXXXXXXXXX/testbdd.php" method="post" enctype="multipart/form-data" name="formSaisie" target="_self"> <p> <label for="textfield">Phrase 1:</label> <input type="text" name="phrase1" id="phrase1"> </p> <p> <label for="textfield2">Phrase 2:</label> <input type="text" name="phrase2" id="phrase2"> </p> <input type="submit" name="Suivant" id="Suivant" value="Envoyer"> </form>

---

La page pour l'envoi à la table s'appelle testbdd.php. Ici, je fais le test avec, pour la phrase 1 : htmlspecialchars et ENT_QUOTES et pour la phrase 2: mysqli_real_escape_string()

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

<?php include( '../script/connection.inc.php' );   $sphrase1 = htmlspecialchars( $_POST[ 'phrase1' ], ENT_QUOTES ); $sphrase2 = mysqli_real_escape_string( $conn, $_POST[ 'phrase2' ] );   $sql = "INSERT INTO `testbdd` ( `id`,`phrase1`,`phrase2`) VALUES ('','" . $sphrase1 . "','" . $sphrase2 . "')";   if ( mysqli_query( $conn, $sql ) ) { echo "Nouveau enregistrement créé avec succès";   } else { echo "Erreur : " . $sql . "<br>" . mysqli_error( $conn ); } mysqli_close( $conn ); header( "Location: ../consult.php" ); ?>

---

Pour mon test, j'ai tapé deux phrases avec des apostrophes et des accents: phrase 1: L'oreille est là, phrase 2: L'œil est bleuté

Voici les résultats sur la table:

Pour la phrase 1: L'oreille est là
Pour la phrase 2: L'œil est bleuté

Enfin je créé une page de consultation pour avoir l'affichage de mes 2 phrases. Le fichier s'appelle consult.php

Code:

---

1 2	echo $sqlRow['phrase1'].'<br>'; echo $sqlRow['phrase2'];

---

A l'affichage j'ai:

L'oreille est là
L'œil est bleuté

Pour résumé, pour voir si j'ai bien compris,

htmlspecialchars et ENT_QUOTES (pour les apostrophes) n'ont d'effet "que" sur l'affichage mais pas dans la table
mysqli_real_escape_string() (pour les apostrophes) a un effet sur sur l'affichage et la table

En lisant les forums, sans être spécialiste, j'ai l'impression qu'il y a débat entre les deux possibilités. Si j'ai bien compris htmlspecialchars et ENT_QUOTES protégeraient des failles XSS tandis que l'autre solution protégerait des injections SQL.

Je pense aussi que cela doit dépendre du projet à réaliser.

Est-ce que j'ai à-peu-près correctement compris ?

Merci

A bientôt

Citation:

---

htmlspecialchars et ENT_QUOTES (pour les apostrophes) n'ont d'effet "que" sur l'affichage mais pas dans la table

---

Non, car comme tu l'as dit dans la base tu as la valeur "L'oreille est là".
=> Maintenant essaie de sortir cela sur un CSV, un PDF, ou simplement un terminal, l'entité HTML ' serait affichée telle quelle.

Citation:

---

mysqli_real_escape_string() (pour les apostrophes) a un effet sur sur l'affichage et la table

---

Non, ni l'un ni l'autre. En base tu obtiens bien la valeur saisie à l'origine, sans modifications.

Citation:

---

Enfin je créé une page de consultation pour avoir l'affichage de mes 2 phrases. Le fichier s'appelle consult.php

Code:

---

1 2	echo $sqlRow['phrase1'].'<br>'; echo $sqlRow['phrase2'];

---

---

Ce n'est pas comme cela qu'on affiche du HTML, on affiche du HTML avec htmlspecialchars() :

Code:

---

1 2	echo htmlspecialchars($sqlRow['phrase1']), '<br>'; echo htmlspecialchars($sqlRow['phrase2']);

---

Sinon ton HTML serait faussé si l'utilisateur tapait quelque chose comme <h1>Coucou !</h1> (pour rester sage).

Citation:

---

En lisant les forums, sans être spécialiste, j'ai l'impression qu'il y a débat entre les deux possibilités.

---

Il n'y a aucun débat. Les bonnes pratiques sont :
1. On échappe le SQL avec les méthodes appropriées (mysqli_real_escape_string() ou mysqli_prepare())
2. On échappe le HTML à l'affichage