Pb sécurisation script
Résolu
loute08
Messages postés
227
Date d'inscription
Statut
Membre
Dernière intervention
-
Mimiste Messages postés 1149 Date d'inscription Statut Membre Dernière intervention -
Mimiste Messages postés 1149 Date d'inscription Statut Membre Dernière intervention -
Bonjour,
Dans le cadre de mon stage je dois réaliser un site, pour le valider je dois passer par un responsable, celui m'a dit qu'il me manquait quelque petits détails de sécurisation pour qu'il soit validé, or si je ne le valide pas, mon stage n'est pas non plus validé et du coup mon année non plus...
Voici ce qu'il m'a dit.
Pour les données que vous récuperez via les les forms, il faut absolument les vérifier et les sécuriser autrement qu'avec des addslashes.
Regardez 'htmlspecialchars', et autres, sinon tout insertion dans la BDD reste sujette à malveillance...
Les fichiers de traitement "contact_message.php" et "newsletter-2.php" sont à sécuriser. Dans le 2ème, en ajoutant aussi un case 'default' dans le switch.
Ne ***jamais*** utiliser de donnée provenant d'un form sans la traiter et la verifier avant de l'utiliser dans une requete =>
... FROM newsletter WHERE email='". $_POST['email'] ."' == JAMAIS ça !!!!
Et pour verifier les adresses mails (ou meme d'autres champs), il y a les regex : http://www.phpit.net/code/valid-email/
Voilà quelqu'un pourrait m'aider?
Dans le cadre de mon stage je dois réaliser un site, pour le valider je dois passer par un responsable, celui m'a dit qu'il me manquait quelque petits détails de sécurisation pour qu'il soit validé, or si je ne le valide pas, mon stage n'est pas non plus validé et du coup mon année non plus...
Voici ce qu'il m'a dit.
Pour les données que vous récuperez via les les forms, il faut absolument les vérifier et les sécuriser autrement qu'avec des addslashes.
Regardez 'htmlspecialchars', et autres, sinon tout insertion dans la BDD reste sujette à malveillance...
Les fichiers de traitement "contact_message.php" et "newsletter-2.php" sont à sécuriser. Dans le 2ème, en ajoutant aussi un case 'default' dans le switch.
Ne ***jamais*** utiliser de donnée provenant d'un form sans la traiter et la verifier avant de l'utiliser dans une requete =>
... FROM newsletter WHERE email='". $_POST['email'] ."' == JAMAIS ça !!!!
Et pour verifier les adresses mails (ou meme d'autres champs), il y a les regex : http://www.phpit.net/code/valid-email/
Voilà quelqu'un pourrait m'aider?
A voir également:
- Pb sécurisation script
- Script vidéo youtube - Guide
- Mas script - Accueil - Windows
- Ghost script - Télécharger - Polices de caractères
- Script cmd - Guide
- Script download - Télécharger - Édition & Programmation
5 réponses
Ha bah non jamais ça c'est clair
Il est trés facile avec ce genre de script d'effectuer une injection SQL
Pour eviter ça utilise ton addslashes, ainsi que :
$Email = mysql_real_escape_string($Email);
Il est trés facile avec ce genre de script d'effectuer une injection SQL
Pour eviter ça utilise ton addslashes, ainsi que :
$Email = mysql_real_escape_string($Email);
alors ouaip en fait moi pour récupérer des variables je fonctionne comme ça
if(isset($_POST['variable']))
{
$variable = intval(hmlentites($_POST['variable']));
//hmlentites enléve le "danger" du code html
//intval vérifie que je récupére bien un int (dans le cas où ma variable doit être un entier...), y a aussi srtval, floatval etc...
//trim est pas mal aussi ça permet d'enlever les espaces inutiles (genre au début et à la fin de ta variable)
}
une fois que t'as récupéré $_POST['variable'], que tu l'as "néttoyer" et affecter à $variable tu n'utilises plus que $variable attention tout ça ne remplace pas addslashes au moment d'éxécuter ta requete...
if(isset($_POST['variable']))
{
$variable = intval(hmlentites($_POST['variable']));
//hmlentites enléve le "danger" du code html
//intval vérifie que je récupére bien un int (dans le cas où ma variable doit être un entier...), y a aussi srtval, floatval etc...
//trim est pas mal aussi ça permet d'enlever les espaces inutiles (genre au début et à la fin de ta variable)
}
une fois que t'as récupéré $_POST['variable'], que tu l'as "néttoyer" et affecter à $variable tu n'utilises plus que $variable attention tout ça ne remplace pas addslashes au moment d'éxécuter ta requete...
Je suis en licence tic option ctic donc moi je suis plus axé graphisme et compagnie ben pour les requetes sql g super galéré, y a d gens du forum qui m'ont aidé, des gens de ma classe mais là je suis toute seule...
super je sais pas ce que sais licence tic option ctic, ça aurais été bien de dire ce que c'est en français
bon revenons en à ton problème:
1 - l'utilisateur de ton site remplis ton formulaire
2 - la 1° étape consiste à vérifier que ce connard n'a pas mis n'importe quoi dans tes champs, notamment du code "executable" style javascript pour ça la solution c'est htmlentites qui transforme tous les caractéres spéciaux html comme < en < > en > " en "e; comme ça si dans un champs y a une balise html elle sera pas interprétée
3 - les variables de formulaires sont des variable de type string (chaine de caracteres) donc si t'as besoin de récupérer un nombre pour faire un calcul par exemple, il faut le convertir en nombre avec intval() pour un entier, floatval() pour un flottant.
4 - donc ça c'était pour expliquer mon exemple du dessus maintenant tes variables sont "propres" mais il faut encore se méfier déjà tu t'es pas fait chier à néttoyer les variables pour rien alors tu les utilises, tu laisses tomber les variables $_POST[''].
5 - lorsque tu fait une requete mysql tu fait plus :
INSERT INTO ma_table VALUES('".addslashes($_POST['variable'])."') parce que $_POST['variable'] n'est pas propre (ou vérifié)
mais tu fais :
INSERT INTO ma_table VALUES('".addslashes($variable)."') parce que $variable est propre (ou vérifié)
ça évite qu'un connard te fasse mettre n'importe quoi dans ta table en rajoutant des quotes (qui ne sont pas transformé avec htmlentites)
addslashes permet d'échapper les caractéres avec un antislash \ comme ça mysql comprends que le quote ' fait partie de la variable et qu'il n'indique pas qu'on passe au champ suivant.
2 sites trés bien pour apprendre (mieux que certains profs que j'ai eu...) :
https://www.vulgarisation-informatique.com/variables-constantes.php
https://openclassrooms.com/fr/
et la bible :
https://www.php.net/
bon revenons en à ton problème:
1 - l'utilisateur de ton site remplis ton formulaire
2 - la 1° étape consiste à vérifier que ce connard n'a pas mis n'importe quoi dans tes champs, notamment du code "executable" style javascript pour ça la solution c'est htmlentites qui transforme tous les caractéres spéciaux html comme < en < > en > " en "e; comme ça si dans un champs y a une balise html elle sera pas interprétée
3 - les variables de formulaires sont des variable de type string (chaine de caracteres) donc si t'as besoin de récupérer un nombre pour faire un calcul par exemple, il faut le convertir en nombre avec intval() pour un entier, floatval() pour un flottant.
4 - donc ça c'était pour expliquer mon exemple du dessus maintenant tes variables sont "propres" mais il faut encore se méfier déjà tu t'es pas fait chier à néttoyer les variables pour rien alors tu les utilises, tu laisses tomber les variables $_POST[''].
5 - lorsque tu fait une requete mysql tu fait plus :
INSERT INTO ma_table VALUES('".addslashes($_POST['variable'])."') parce que $_POST['variable'] n'est pas propre (ou vérifié)
mais tu fais :
INSERT INTO ma_table VALUES('".addslashes($variable)."') parce que $variable est propre (ou vérifié)
ça évite qu'un connard te fasse mettre n'importe quoi dans ta table en rajoutant des quotes (qui ne sont pas transformé avec htmlentites)
addslashes permet d'échapper les caractéres avec un antislash \ comme ça mysql comprends que le quote ' fait partie de la variable et qu'il n'indique pas qu'on passe au champ suivant.
2 sites trés bien pour apprendre (mieux que certains profs que j'ai eu...) :
https://www.vulgarisation-informatique.com/variables-constantes.php
https://openclassrooms.com/fr/
et la bible :
https://www.php.net/
N'oublie pas mysql_real_escape_string($chaine) comme fonction de protection de données, c'est aussi important contre l'injection SQL
la doc :
https://www.php.net/mysql_real_escape_string
la doc :
https://www.php.net/mysql_real_escape_string
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question