Peut-un pirate informatique malveillant modifier une variable de message cachée

Question

Je sais qu'un POST peut être falsifié en termes de domaine d'origine, mais qu'en est-il de la possibilité de modifier les variables des variables POST cachées dans mon HTML? Je crains que quelqu'un puisse modifier la valeur "montant" dans mon formulaire PayPal de ceci :

à ceci :

ou quelque chose de similaire. Merci.

Answer 1

Oui, il est très facile pour quiconque de modifier vos variables de formulaire. Peu importe qu'elles soient en GET ou en POST.

Règle de sécurité Web n°1 : Ne jamais faire confiance à aucune entrée utilisateur. Aussi exprimé comme "Tous les utilisateurs sont des pirates malveillants" ou quelque variante de cela.

Réponse au commentaire : La solution est de connaître toutes les valeurs correctes du côté serveur, sans avoir à les passer par le côté client (Javascript). Ainsi, indépendamment de ce que le formulaire dit, vous connaissez déjà le prix. Utilisez simplement la même valeur que celle utilisée pour remplir le formulaire en premier lieu.

Answer 2

Mise à jour 2020:

L'OWASP aborde ce sujet dans "Injection Theory", où les applications acceptent des données de sources non fiables, non contrôlées ou potentiellement compromises.

L'injection est une tentative d'attaque visant à envoyer des données à une application d'une manière qui modifiera le sens des commandes envoyées à un interpréteur.

Consultez cette "feuille de triche" de l'OWASP pour un aperçu des mesures d'atténuation pouvant être mises en œuvre pour mieux sécuriser les points de terminaison basés sur REST.

---

Oui, c'est très simple à faire avec les outils d'inspection du navigateur, le JavaScript, cURL et d'autres outils.

---

Vous ne devriez pas vous fier au champ amount étant ce que vous aviez initialement transmis dans la réponse au client. Une approche plus sécurisée consisterait à se fier à un identifiant pour un article, que vous pouvez associer à un prix sur le serveur (un environnement plus contrôlé).

Answer 3

Oui, il est possible de changer cette valeur en utilisant JavaScript. Si vous n'avez pas pratiqué l'utilisation de JavaScript, vous pouvez également faire le test en utilisant les outils de développement de Google Chrome.

En fait, c'est l'une des principales raisons de ne pas s'appuyer sur l'entrée de l'utilisateur.

Answer 4

Oubliez JavaScript et les outils de navigation. Veuillez comprendre que je peux envoyer N'IMPORTE quel cookie, POST et GET argument (paires clés-valeurs) que je veux, peu importe s'il s'agit d'un formulaire pour eux. (Voir cURL)

Frank a dit : "Au magasin, vous verriez très rarement des clients remplir leur chariot, puis dire à la caissière combien ils doivent payer."

Essayez de voir les choses de cette façon. Le navigateur (pas l'utilisateur) est le client et le serveur est la caissière. Toute information qui circule du navigateur vers le serveur peut être ce que je veux.

Answer 5

Oui. Cela devient encore pire car ils n'ont même pas besoin de modifier votre page pour le faire. Un utilisateur pourrait utiliser n'importe quel éditeur de texte pour construire une page html avec un formulaire rempli de champs de texte, le charger depuis le disque local, les remplir avec ce qu'il veut et appuyer sur soumettre. D'un autre côté, cela apparaîtra dans certaines valeurs d'en-tête.

Ou s'ils sont vraiment déterminés, ils peuvent se connecter au port 80 de votre serveur via telnet et falsifier l'intégralité de la requête HTTP, y compris les en-têtes.

Il n'y a pas un seul octet de la requête entrante en qui vous pouvez avoir confiance.

Cela dit, il existe des solutions connues à ces problèmes qui sont généralement mises en œuvre en termes de hachages, de signatures et de cryptographie, mais je n'en sais pas assez pour suggérer où les trouver.