Discussion :

[jordan01]

Bonjour,
j'ai un freelance qui a développé en PHP un formulaire de commande.
La 1ère page possède les champs classiques: nom, prénom, adresse, code postal, ville, téléphone etc.
Quand on clique sur le bouton submit ça fait un récapitulatif de la commande.
Je lui ai demandé de ne pas stocker en base de données ces informations tant que le client ne procédait pas au paiement (via Stripe).
Mais je voulais que le client puisse modifier son adresse, son nom, prénom etc si besoin.
Donc le développeur a bien fait un lien avec "modifier mes informations" qui redirige le visiteurs vers la page 1 du formulaire de commande et toutes les informations préalablement remplies sont bien présents dans les champs (pour ne pas qu'il ait à tout retaper).
L'URL de la première page est alors du type : index.php?data=kokokdzhdhggfkdhakjfkjsldfjjzfdhksqfhzkjhdkjzevhlkzehvkezhvjlk
La suite de caractère est énormissimme.
En soit, je ne trouve pas ça extrêmement dérangeant. Mais je voudrais savoir si un pirate ajoute une suite de caractère "anormale" peut-il injecter quelque chose de malicieux sur mon serveur par exemple ?

J'ai essayé de mettre une suite de caractère aléatoire, et j'ai le message d'erreur : "Warning: Invalid argument supplied for foreach() in /home/***************/form-commande/index.php on line 15"

Merci beaucoup pour votre aide
Passez un bon week-end

[cavo789]

Bonjour

Tu as donc une page index.php qui serait un formulaire et tu as dans l'URL une variable nommée data et qui contient une très longue valeur.

Est-ce un virus ? Impossible à te dire sans en savoir plus.

Si tu as un formulaire et qu'il y a un champ unique de nommant data et que ce formulaire est en method GET et non POST cela explique alors l'URL que tu rencontres.

On peut imaginer que la valeur est encodée en base64 (généralement tu trouveras un ou plusieurs signes = à la fin de la valeur).

Tu trouveras sur l'un de mes sites un outil pour décrypter un tel code : https://base64.avonture.be/

Colle la valeur de data dans ma page et voit ce qu'il se passe.

[jordan01]

Merci pour ta réponse

Alors oui effectivement c'est bien chiffré en base64 car j'ai c/c dans ton décrypteur et effectivement il y a tous les éléments qui correspondent à mes tables Mysql.

Donc, je me demande si un pirate pourrait injecter du code malveillant en le cryptant en base64 et en tapent l'URL de monsite.com/form/index.php?data=virus-crypté-en-base64

[CosmoKnacki]

Je lui ai demandé de ne pas stocker en base de données ces informations tant que le client ne procédait pas au paiement

Pourquoi? Quelqu'un qui renseigne ces données est responsable de ses actes, donc de ce coté là pas de problèmes du point de vue éthique. Et, quand bien même la transaction n'aboutirait pas, rien n'empêche au delà d'un certain délai de supprimer ces informations de la base si la transaction n'a pas abouti.

j'ai un freelance ...

Dans ce cas ce n'est pas ton problème mais le sien. Maintenant si tu n'as pas confiance en ce freelance, engages en un autre.

[mathieu]

il est techniquement possible de protéger ces données dans l'url pour que vous ne vous fassiez pas pirater.
maintenant la question est de savoir si le développeur a mis cette protection. je suppose que si vous avez assez confiance en lui pour exécuter son code sur votre site, il suffit de lui demander et de lui faire confiance dans sa réponse.

d'un autre côté, c'est au développeur d'expliquer ce qu'il fait, de détailler les fonctionnalités pour lesquelles vous payez. donc le développeur aurai dû vous rassurer dés le début et vous n'auriez pas eu besoin de venir poser la question ici.

[CosmoKnacki]

donc le développeur aurai dû vous rassurer dés le début et vous n'auriez pas eu besoin de venir poser la question ici.

D'accord mais en même temps, difficile de faire face à toutes les psychoses.

[cavo789]

[QUOTE=jordan01;12031048]
Alors oui effectivement c'est bien chiffré en base64 car j'ai c/c dans ton décrypteur et effectivement il y a tous les éléments qui correspondent à mes tables Mysql./QUOTE]
Tu parles d'une instruction SQL complète ? Je suppose et j'espère que non.

Pour la partie virus, logiquement non mais tout est possible si la programmation php est vraiment, totalement, mal conçue.

Dans l'absolu, ce formulaire est supposé écrire en base de données des valeurs dans des tables connues à l'avance. En principe, rien d'autre que ça. Donc est-ce possible d'injecter un virus, logiquement non.

Mais voilà, il faudrait lire le code pour en comprendre le mode de fonctionnement et te répondre.

Sache que le fait de passer la valeur data par URL est quand même surprenante. Ton développeur pouvait utiliser la méthode POST dans le formulaire pour éviter une URL comme celle qui t'interpelle. Pourquoi a-t-il utilisé GET ? S'il n'a pas de réponse à cette question toute banale alors je me poserais des questions sur son niveau de compétences...

[jordan01]

Pourquoi? Quelqu'un qui renseigne ces données est responsable de ses actes, donc de ce coté là pas de problèmes du point de vue éthique. Et, quand bien même la transaction n'aboutirait pas, rien n'empêche au delà d'un certain délai de supprimer ces informations de la base si la transaction n'a pas abouti.

Pour éviter les bots qui renseignent le form de commande et qui peuvent bourriner comme des fous. Oui il y a aussi possibilité de mettre un captcha, mais ça peut aussi baisser le taux de conversion (des humains).

Dans ce cas ce n'est pas ton problème mais le sien. Maintenant si tu n'as pas confiance en ce freelance, engages en un autre.

Je suis le gérant de mon entreprise et le propriétaire du site. C'est bien mon problème.

il est techniquement possible de protéger ces données dans l'url pour que vous ne vous fassiez pas pirater.

Pourrais-tu STP m'indiquer le nom de la fonction/technique ? Que je puisse regarder des tuto sur Internet et vérifier le code que j'ai.

d'un autre côté, c'est au développeur d'expliquer ce qu'il fait, de détailler les fonctionnalités pour lesquelles vous payez. donc le développeur aurai dû vous rassurer dés le début et vous n'auriez pas eu besoin de venir poser la question ici.

C'est pas faux mais la théorie est souvent différente de la pratique. Certains freelance (développeurs ou non, ça marche aussi avec les mécaniciens et les massons) disent que tout va bien alors que pas du tout. Et dans tous les cas je préfère le : trust but verify.

Tu parles d'une instruction SQL complète ? Je suppose et j'espère que non.

Dans la suite de caractères que j'ai c/c dans ton décodeur, je peux voir que ça commence par : "{"prenom":"Cecile","nom":"ddd","email":"ddddd@dddd.com","tel":"0600000000","address":"
Donc ce sont bien les informations du formulaire qui seront ensuite intégrés à la base de données. Mais il n'y a pas d'élements comme "INSERT" ou autre dans ce chiffrement base64. J'espère que c'est bon signe ^^ ?

[mathieu]

Pourrais-tu STP m'indiquer le nom de la fonction/technique ? Que je puisse regarder des tuto sur Internet et vérifier le code que j'ai.

la technique consiste à vérifier de la même façon les données venant de l'url et les données saisies par l'utilisateur. il s'agit de données extérieures donc un utilisateur malveillant peut mettre ce qu'il veut.

et je suis d'accord avec cavo789 que le passage par l'url n'est pas un fonctionnement habituel, je trouve que ça ne donne pas un résultat très joli pour l'utilisateur.
les données peuvent par exemple être stockées dans une session php.

[jordan01]

donc un utilisateur malveillant peut mettre ce qu'il veut

Ce qu'il veut c'est uniquement du texte en "lecture seul" ? Ou du texte comme du code qui peut être interprété par mon site donc ouvrir des fichiers malveillant, faire fuiter des données etc. ?

[jordan01]

Et pour info, j'ai voulu faire une seconde fois affaire à ce développeur. Je lui ai envoyé un acompte de 400€ et depuis plus de nouvel de lui (comme 1/2 que je fais un acompte).

[cavo789]

Ce qu'il veut c'est uniquement du texte en "lecture seul" ? Ou du texte comme du code qui peut être interprété par mon site donc ouvrir des fichiers malveillant, faire fuiter des données etc. ?

Les données que tu as décodées sont donc totalement normales (nom, prénom, numéro de téléphone,...) et ces données de ce qu'on comprends de ce que tu dis, seront stockées en base de données.

Ce n'est donc pas du code exécutable, pas de souciI ici... mais que se passe-t-il si on tente de faire du SQL injection (je te laisse chercher sur le net).

Tu aurais donc une instruction SQL de type INSERT INTO dans le script php, comment cette instruction va se comporter avec des données construites pour faire du SQL injection ? Est-ce que le code php validé les données (un numéro de téléphone doit être des chiffres et peut-être des points et traits d'union, un nom ne peut pas contenir certains caractères,...). Si le code php valide les données, okido. S'il ne le fait pas, parce que SQL injection, il peut y avoir un risque comme p.ex. l''insertion d'un nouvel admin dans le site, la divulgation de la liste des utilisateurs,... C'est ça le concept de SQL injection dont ton développeur doit absolument prendre des mesures préventives.

Là, ici et tout de suite, je dirais qu'il n'y a pas de preuves qui laissent à croire que c'est mal programmé mais tu sembles le craindre aussi prends le temps de lire le code php et de voir si tu y vois des monstruosités.

[Mila1a]

Bonjour
Il faut filtrer les $get/$post variables sinon vous pouvez avoir une attaque sql injection ou xss ou autres.
Cordialement.

[domi65]

les données peuvent par exemple être stockées dans une session php.

Oui, mais...
Si le client refuse les cookies, alors les données de sessions sont passées en get 🤪

En fait, on parle ici de "décoration". La seule chose qui change c'est l'esthétique de l'url, les données n'étant pas plus sûres envoyées en post qu'en get.