Formulaire bien sécurisé

[michel.leonard]

salut a tous, amis WRInautes

je me posais une question ! comme d'habitude ... Selon vous comment faire un formulaire sécurisé ? Je vais vérifier chaque champ par expression rationnelle et les injecter dans une base SQL ... Mais quelle est la meilleure méthode pour passer d'un bouton envoi, vers une variable php sans modifier le contenu de l'url ?

Merci a celui ou celle qui m'apportera une réponse fiable...


Bonne fin de soirée, bonne journée à tous...

 

[ap34df]

Mais quelle est la meilleure méthode pour passer d'un bouton envoi, vers une variable php sans modifier le contenu de l'url ?

La méthode $_POST.

Sinon, en vrac...
Traitement du formulaire sur une autre page.php
Vérif via les session que la page de traitement n'est résolu que si elle est appelée depuis la page du formulaire
Vérif des données soumises (comme tu le dis)
Question anti-bot
Traitement mysqli_real_escape_string avant intégration en bdd

 

[Julia41]

Pour l'insertion SQL tu dois échapper comme dit Ehplod.
Si tu attends un entier quelquepart (un champ "id" par exemple) tu regardes si elle est pas = à 0 après un int($ta_var).

Tu peux regarder du côté de fitler_var qui a des filtres de validation "est-ce que l'URL est valide" (FILTER_VALIDATE_URL/IP) et des filtres de nettoyage (FILTER_SANITIZE).

Tu as des choix à faire aussi : est-ce que je veux ou non de l'HTML dans ma base, si j'en veux est-ce que je le stock échappé (je n'aurais donc pas à l'échapper) les fonctions strip_tags peuvent aider pour supprimer l'html, pour l'affichage un htmlspecialchars/entities peut être nécessaire.

Tu peux généralement tester contre les XSS en indiquant :

<script>alert (document.cookie);</script>
ou
"><script>alert (document.cookie);</script>

dans tes input de type text.
Le second parchera dans le cas où tu aurais un :

if($erreur){
... on affiche le formulaire
<input type="text" value="<?php echo $_POST['ma_var']; ?>" />

Ce code génerera donc:
<input type="text" value=""><script>alert (document.cookie);</script>" />[/code]
d'où un échappement nécessaire en htmlspecialchars.

Généralement je fais de la validation "secondaire" aussi (pas sécure mais qui limite les performances d'un hack):
si j'ai un varchar(255) dans ma base et qu'on me soumets une chaine de plus de 256 caractères c'est très louche, surtout si c'était un champ pseudo.