Discussion :

[reventlov]

Bonjour,

Récemment sur un de mes a été la cible d'un hack. J'ai une vague idée de la manière dont la personne s'y est prise mais j'aimerais avoir votre avis.

Voilà : j'ai un formulaire html qui une fois validé envoi vers un fichier php de traitement pour la connexion avec un système de paiement en ligne par carte bleue. une personne a trouvé le moyen de modifier le prix avant traitement pour avoir a payer moins cher. En regardant mon code, je pense que le seul endroit où cette personne ait pu agir est au niveau du formulaire. Ce formulaire contient entre autre une balise hidden ayant pour value le montant à payer. Le tout est envoyé au fichier de traitement de paiement en ligne qui fait la connexion avec le terminal de paiement. Les données du formulaire sont envoyée en post évidemment. Je pense que la personne a trouvé le moyen de modifier la valeur de la balise hidden du montant avant d'envoyer le formulaire vers le fichier de traitement de la banque. Le schema de la procédure :

formulaire (A)=> fichier de mise en forme des données de paiement (b)=> page du terminal de paiement de la banque

La liaison (A) se fait en http/POST, la liaison (B) se fait en https/POST. Comme la liaison (A) n'est pas cryptée je ne vois que cet endroit pour agir et modifier les données.

Concrètement comment vous y prendriez-vous pour reproduire ce hack ? C'est dur de trouver des traces même dans les fichiers de log du serveur car je ne sais pas trop quoi chercher.

[mathieu]

Pour éviter cela, vous devez vérifier que la somme payée correspond bien à la somme de la commande et ensuite vous pouvez valider la commande.
Vous avez fait vous même le code de validation de la commande ?

[reventlov]

Merci pour la réponse rapide ! Mais j'ai trouvé comment il a procédé, j'ai pu reproduire exactement ce qu'il a fait. C'est une faille de débutant : Il a tout simplement affiché le code source de la page avec chrome (inspecter le code), puis modifié le code à la volée (chrome le permet) puis dans la console javascript il a tapé document.LeNomDuFormulaire.submit(); et ça marche o_O ... je devrais savoir que ce genre de chose est possible et j'ai un peu honte... Mais d'un autre côté je trouve absolument aberrant que ce genre de chose soit possible avec un navigateur. Qu'on puisse modifier le code de la page ok mais renvoyer le formulaire modifié de la page aussi facilement... On m'aurait posé la question j'aurai répondu "mais non voyons, ce serait aberrant qu'une telle chose soit permise" (ce que je pensais). Et bien je me plante... Donc la solution est, je suppose, d'encrypter le code de mes pages html c'est ça ? Ou alors faire en sorte que les données post soient envoyées directement du serveur mais pas d'une page qui s'affiche dans un navigateur. Je suis un peu perdu pour trouver une solution rapide. Les sites sont anciens mais en production et ils brassent bcp d'utilisateurs. Il faut que je trouve une solution rapide sans avoir à tout restructurer... Je suis un peu perdu là... La solution la plus rapide à mettre en oeuvre ce serait quoi ?

[Marco46]

"mais non voyons, ce serait aberrant qu'une telle chose soit permise"

C'est impossible d'empêcher l'utilisateur du navigateur de modifier la page interprétée par son navigateur. Ça n'a aucun sens, c'est son navigateur sur sa machine.

Et bien je me plante... Donc la solution est, je suppose, d'encrypter le code de mes pages html c'est ça ?

On dit chiffrer et pas encrypter ni crypter, c'est un anglicisme qui ne veut rien dire.

Non la solution c'est de prendre le temps de lire la documentation de ton fournisseur de solution de paiement en ligne, il y a forcément un passage sur le contrôle des formulaires saisis. Généralement ce qui se passe c'est que le formulaire qui va être affiché à l'utilisateur va être généré par ton serveur qui au passage va calculer une somme de contrôle qu'il va placer dans un champ hidden du formulaire pour vérifier après soumission que le formulaire n'a pas été modifié par l'utilisateur (en recalculant la somme du formulaire soumis et en la comparant à la précédente) et si tout va bien tu peux rediriger l'utilisateur sur le service de paiement en ligne.

Le chiffrement des connexions ça sert à empêcher un tiers (et pas l'utilisateur !) de lire la transaction pour en extraire des données sensibles.

Il faut que je trouve une solution rapide sans avoir à tout restructurer...

La solution c'est de faire correctement son travail en amont en comprenant les technologies qu'on utilise surtout quand on fait joujou avec les cartes bleues de ses clients.

Dans ton cas, puisque visiblement tu n'as pas la moindre notion de sécurité informatique ni d'architecture web, le plus rapide c'est de lire la documentation de l'éditeur de service en ligne et d'appliquer les recommandations quitte à contacter leur support pour te faire aider.

[reventlov]

La problème ne se situe pas entre le script de mise en forme des données qui les envoi vers le TPE, et dans ce cas j'utilise l'API fournie par le prestataire qui effectivement crée une somme de contrôle etc... Le problème se situe au niveau de la transmission des données à ce script. Effectivement ça aurait été plus propre que ces données soient directement injectée dans l'API bancaire autrement que par un formulaire mais malheureusement c'est la cas et j'ai récupéré le site tel quel. C'est à dire que la possibilité de modifier la somme existe avant le traitement bancaire. Les données bancaires des clients ne sont pas en danger, du moins de mon fait, car entièrement gérées par la banque. Par contre la possibilité de modifier le prix d'un produit existe. Ce que j'ai fais en attendant de restructurer pas mal de chose, car il faut bien que le système reste en ligne, c'est de chiffrer la somme transmise à L'API de la banque. Cette somme apparaît bien dans la source de la page mais chiffrée. Dit autrement si quelqu'un essaye de placer dans la balise hidden (c'est une balise hidden) un montant non chiffré le système le jette. Merci pour vos infos