Discussion :

[chrtophe]

Bonsoir,

J'aurais besoin de conseils sur le traitement de variables récupérés depuis un formulaire afin de sécuriser leur contenu et d'avoir des failles de sécurité.

Merci d'avance pour votre retour sur les bonnes pratiques à utiliser.

[cavo789]

Bonsoir

Si ton projet utilise composer, tu peux te reposer sur des librairies existantes comme celle de Laravel : illuminate/validation

Tu en fais un composer require puis, dans ton code, tu auras accès à toutes les rules de Validation : https://github.com/illuminate/validation

Voici un petit exemple trouvé sur GG : https://gist.github.com/spekkionu/e9103993138e666f9f63 mais nul doute que tu en trouveras des milliers d'autres.

Bonne soirée et bonne programmation.

[chrtophe]

Merci de ton retour, mais je n'utilise pas Composer.

[Droïde Système7]

Bonjour,

Si ton server, clé de voute du tout, est bien configuré et qu''il tienne la route, sans oublier ses éventuelles màj, que faire de plus ?

Ce n'est pas Christophe que me contredira sur ce point je pense

Sans omettre le blindage/limitations des inputs.

Sans omettre non plus la màj du système de BdD si cela s'appuie dessus.

Mais là, je raisonne sur un formulaire classique, sans passer par exemple sur PHPMailer.

DS7

[cavo789]

Le message de chrtophe indique qu'il s'agit d'une solution php 5.3 et, je présume alors, qu'il s'agit d'un best effort (ne pas investir de trop dans cette vieille solution).

Si le projet n'était pas prévu pour Composer (c'est vraiment pas de chance mais peut-être le développeur original n'avait pas cette compétence), y intégrer composer demande quelques adaptations et c'est peut-être trop "cher" pour le besoin exprimé par chrtophe.

Il y a bien moyen de se passer de Composer mais cela reste alors du chipotage (faut télécharger la dépendance, faire les différents require_once et cela dans le bon ordre, etc.), bref, du chipotage et peut-être alors tout aussi coûteux en temps.

Faudrait donc trouver une librairie de "validation" non basée sur Composer ? Faudrait écumer le web...

On peut aussi tout "se taper à la main" en faisant appel à différentes validations; voir https://www.php.net/manual/fr/filter...s.validate.php

Fastidieux...

[chrtophe]

Si ton server, clé de voute du tout, est bien configuré et qu''il tienne la route, sans oublier ses éventuelles màj, que faire de plus ?

Ma question concerne plus un avis sur les bonnes pratiques pour "sanitiser" les éléments de formulaires pour éviter les failles au niveau site web type XSS ou SQL Injection, etc., pas forcément serveur, serveur sur lequel de toute façon je n'aurais pas la main.

y intégrer composer demande quelques adaptations et c'est peut-être trop "cher" pour le besoin exprimé par chrtophe.

Oui c'est cher, car je ne connais pas. Pour moi composer c'était pour installer des dépendances PHP en ligne de commande. Si c'est bien ça, sur un serveur type mutualisé ça va être compliqué.

Je ne suis pas programmeur de métier. Je ne tiens pas à utiliser spécialement une bibliothèque, plutôt le faire en natif PHP.

Fastidieux

Pas forcément, ça restera des tests simples. L'aspect ou j'ai besoin d'assistance c'est surtout contre failles classiques liés à des saisies foireuses notamment sur les chaines de caractères. De mémoire on utilisait htmlentities et/ou htmlspecialchars mais je ne sais pas si c'est toujours d'actualité

[mathieu]

pour se protéger des injection SQL, il y a les requêtes préparées :
https://www.php.net/manual/fr/mysqli...statements.php
j'ai pris le réflexe de les utiliser dès qu'il y a des paramètres dans une requête même si je suis sûr (ou "je crois être sûr") que les paramètres sont 100 % vérifiés.

ensuite si vous incluez un fichier avec "require", et que le nom du fichier est construit dynamiquement, il vaut mieux lister les noms de fichiers autorisés et ensuite vérifier que le fichier recherché est dans la liste. la plupart des vérifications qui sont faites autrement peuvent être exploitée avec des caractères spéciaux.

et pour ne pas avoir de souci en construisant le code HTML, utilisez htmlspecialchars partout, même si vous êtes sûr que vous n'affichez qu'un nombre ou un texte qui a l'air sécurisé.