bonjour, je ne sais pas si le titre et judicieux mais il me caractérise.
autodidacte en informatique, je développe un site pour mon travail où je mets tout le code dans un formulaire (simple couche), je le présente et le résponsable informatique me dit que niveau sécurité, il n'y a rien du tout.
J'entends pour la première fois de ma vie, de MVC, injection SQL.
Mes recherches sur internet, me font découvrir htmlentities()...
a travers ce petit post, je vous fais part de la synthèse que j'ai pu faire de différents types d'attaques par un hacker et vous présente des solutions à mettre en place.
Il n'y a aucun code, mais plutôt une association de dispositifs à mettre en place de façon à décourager l'envahisseur.
Merci de m'adresser vos remarques (judicieuses et constructives) sur cette article. Si elles vont dans ce sens, du code sera introduit.
Je ne rentre pas trop dans le détail non plus car cet article se veut pour des néophytes, certains traits sont grossiers mais c'est voulu.
ARTICLE
Pour faire très simple, il est possible à un hacker :
1-«d’écouter » un formulaire (identification) afin de récupérer l’identifiant et le mot de passe.
2- d’injecter ou modifier de la donnée fausse dans la base de donnée, voir de la supprimer.
3- de modifier le code des fichiers servant à faire fonctionner le site.
4- de montrer à l’utilisateur un formulaire avec des données qui ne correspondent pas à celles enregistrées dans la base de données (BDD).
Pour ralentir l’action du hacker, car quelques soient les sécurités mises en places, il y a toujours moyen de les contourner, voici plusieurs mesures à mettre en place.
L’architecture MVC
Les différents fichiers qui entrent en jeu dans la réalisation d’un site avec communication à une BDD, se structurent dans une architecture dite « MVC », triple couche.
V pour vue ; c’est ce que l’utilisateur visualise à l’écran.
C pour contrôleur ; dans le contrôleur, on va déterminer toutes les fonctions de l’application.
Exemple : lorsque je vais vouloir valider de la disponibilité, à l’écran (dans la vue), j’appuie juste sur le bouton « Valider »
En fait, je demande au contrôleur d’exécuter la fonction « INSERER », cette fonction fera appel à différents modèles.
M pour modèle ; les modèles auront pour but de vérifier et contrôler les données émises ou reçues vers la BDD.
Les vues sont « chargées » sur l’ordinateur de l’utilisateur.
Les fonctions sont réalisées sur le serveur.
Répartition des fichiers sur le serveur.
Le serveur, est un disque dur où est hébergé le site.
Je propose cette arborescence :
Dossier « public » : contient les images, script de mise en page…du site.
Dossier « private » : contient les vues, le(s) contrôleur(s), les modules…
Le dossier « private » sera protégé de l’extérieur à l’aide d’un fichier .htaccess.
On créera ainsi une zone administrateur sur les droits de création, modification et suppression des fichiers dans ce dossier.
Nous avons ici répondu au 3ème item des actions du hacker.
Un formulaire « config.php »
Ce formulaire aura pour but de créer le lien de connexion entre les différents modules et la BDD.
Détermine l’url (lieu où est stockée la BDD), le nom de la BDD, le mot de passe de connexion.
Définit aussi le type de « hashe » de certaines données notamment le mot de passe (mdp).
Exemple : je tape « test » dans la case mot de passe, une fois passé dans une sorte de moulinette, le mdp se présentera sous la forme ea3fg45pof43.
Ainsi, si un hacker essaye de s’identifier en injectant directement les valeurs (identifiant=test mdp=test), dans le module action « identifier » il sera rejeté.
Empêcher la navigation d’un utilisateur non logué.
Pour éviter une telle chose, nous créerons un « token » de connexion en créant une variable aléatoirement et en la passant dans notre moulinette. Ces variables seront conservées dans une session.
Dans chaque formulaire, on appellera le module « check.php » qui aura pour but d’identifier si la session est correcte. (Lorsqu’une donnée a été moulinée, il n’existe pas de fonction inverse).
Si quelqu’un essaye d’accéder directement à un formulaire, il sera redirigé vers le formulaire de connexion.
Il est possible de donnée une durée de vie à la session.
Contrôler les données envoyées en vue d’une injection, modification ou suppression de la BDD et Retirer les caractères spéciaux.
Contrôler les données aura pour but de contrôler :
Pour un matricule on a une valeur numérique
Pour une date, on a une date au format voulu
….
Pour se faire, utilisation des fonctions (ctype_..., ou filter_var, …)
Nous avons ici répondu au 2nd item des actions du hacker.
Contrôler les données envoyées en vue d’un affichage et Retirer les caractères spéciaux.
Nous utiliserons la même méthode que précédemment. Pour retirer les caractères spéciaux, nous utiliserons la fonction htmlentities ().
Nous avons ici répondu au 4ème et dernier item des actions du hacker.
FIN
merci de votre attention.
suis-je compréhensible? même pour un néophyte?
est-ce que je ne dit pas trop de bêtises?
Partager