MVC et sécurité [Débutant(e)]

[hugodu28]

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.

1.JPG

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é.

2.JPG

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, …)

3.JPG

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?

[grunk]

Répartition des fichiers sur le serveur

Ton dossier privé doit être hors de la racine web. Pas besoin de htaccess , on est certains que quoi qu'il arrive le dossier ne sera pas accessible via le web.

Pour l'admin soit tu l'intègres complètement à ton appli avec des droits spécifique , soit tu fait une seconde application complètement séparée.

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é.

Même si tu hash le mot de passe après le formulaire , il n'empèche qu'il transite en clair au moment de la soumission du formulaire.
La seule solution viable est d'utiliser du https , si tu ne veux pas voir des données sensible transiter en clair.

Il manque également un point important qui est la protection des formulaire des requêtes croisées (CSRF).
On se protège de cela via un token unique et aléatoire pour chaque formulaire.

[hugodu28]

salut gunk,
merci pour ce complément d'info, je ne connais pas https ni le CSRF, je vais essayer de trouver un tuto la dessus. afin de compléter mon propos.

concernant le dossier privé hors de la racine web, j'ai du mal à visualiser:
- comment l'utilisateur peu appeler un formulaire qui n'est pas dans le fichier "www" (serait-ce un index.php dans le www qui redirige sur private/indentifistoi.php ?)
-quelle serait l'adresse de destination d'un formulaire "POST"

[grunk]

serait-ce un index.php dans le www qui redirige sur private/indentifistoi.php ?

C'est ca.
En MVC en général tu n'a qu'un index dans la partie publique qui va venir inclure les autrse fichiers qui eux sont en privée

[hugodu28]

je viens de lire "generalités sur la sécurité d'un site en php"

http://julien-pauli.developpez.com/t...-web-securite/

je comprends pas a quoi correspond la faille CSRF dont on m'a parlé précédement. Mais si la solution est ce fameux "token" aléatoire pas de souci.

Le seul point où je suis peut-être passé au travers lors de ma lecture est de ne pas envoyer en clair le mot de passe lors du "post" du formulaire.

car si j'ai:

Code html :

1
2
3
4
5
<form name="identifistoi" methode="post" action="controle.php"> 
<input name="identifiant" type="text"   />
<input name="mdp" type="password" />
<input type="submit" name="ok" id="ok" value="Valider"  />
</form>

$identifiant et $mdp seront bien les valeurs entrées dans le champs sans passer à la moulinette.

comment fait-on le https?

[grunk]

La faille CSRF est abordée dans cette partie de l'article. y'a même un exemple succin de résolution du problème.

comment fait-on le https?

Ca se fait au niveau du serveur web (apache en général). Certains hébergeur le propose par défaut d'autre non.
Si les certificats sont installé et le serveur configuré il n'ya rien de spécial à faire si ce n'est utiliser https://monadresse au lieu de http://monadresse et éventuellement faire une redirection pour forcer https.

Mais pour un simple identification d'un petit site ça n'a aucun intérêt. Intercepter les identifiants ça implique une attaque du type "man in the middle" pas évidente à mettre en place.

[hugodu28]

ok merci, pour les infos je fais les ajouts de texte et je poste ça.

[hugodu28]

RE je poste l'intégralité de l'article en rouge les modifes.

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.

1.JPG

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.
Deux solutions sont possibles pour l’arborescence :

1ère solution :
Les dossiers « public » et « private » sont dans le dossier « www » du serveur.
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.
2ème solution :
Le dossier « public » est dans le dossier « www » avec un formulaire index.php qui redirige vers les formulaires « private ».
Le dossier « private » est au-dessus de « www »

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é.

2.JPG

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, …)

3.JPG

Nous avons ici répondu au 2nd item des actions du hacker.

S’assurer que les données proviennent d’un formulaire du site.

Pour se faire, nous créons encore un token aléatoire avec « hash » sur le formulaire émetteur via un cookie et vérification du token sur le formulaire récepteur. On peut aussi attribuer une durée de vie à cette cession (temps estimé pour remplir le formulaire).

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.

Prise en compte des messages d’erreur.

Certaines de ces attaques, si elles aboutissent, peuvent faire générer un message d’erreur indiquant des données sensibles comme le chemin complet des fichiers.
Il faut créer une fonction de gestion des erreurs, celle-ci renverra via un mail, l’ensemble des erreurs.
Le contenu du message contiendra (n° erreur ; message php ; fichier concerné).

[ABCIWEB]

Envoyé par hugodu28

je viens de lire "generalités sur la sécurité d'un site en php"

http://julien-pauli.developpez.com/t...-web-securite/

je comprends pas a quoi correspond la faille CSRF dont on m'a parlé précédement. Mais si la solution est ce fameux "token" aléatoire pas de souci.

Le seul point où je suis peut-être passé au travers lors de ma lecture est de ne pas envoyer en clair le mot de passe lors du "post" du formulaire.

car si j'ai:

Code html :

$identifiant et $mdp seront bien les valeurs entrées dans le champs sans passer à la moulinette.

comment fait-on le https?

Sans https il y a une solution intermédiaire qui consiste à hasher le mot de passe concaténé à un grain de sel côté client c'est à dire avec javascript. A la soumission du formulaire (avant l'envoi du post) tu mets le résultat du hash dans un input de type hidden et tu efface le champ password (tout ça avec javascript). Ainsi ne transite dans les tuyaux qu'un hash qui n'est utilisable qu'une seule fois pour peu que le sel change à chaque chargement de ton formulaire et ton mot de passe est protégé. C'est assez facile à mettre en place et procure un niveau de sécurité supplémentaire appréciable.

[ABCIWEB]

Envoyé par hugodu28

Pour faire très simple, il est possible à un hacker :
...
3- de modifier le code des fichiers servant à faire fonctionner le site.
...

Pour que ce soit possible il faut
- soit qu'il y ait une faille dans un de tes scripts
- soit que le serveur lui même soit piraté (car mal géré ou que les identifiants de connexion aient été volés)
...et dans ces cas là aucune arborescence quelle qu'elle soit ne pourra te protéger.

[hugodu28]

Merci pour l'info,
sur GDS. J'ai lu se tuto
http://guillaume-affringue.developpe...?page=3#LIII-A
ça me parait bien qu'en penses-tu?
pour compléter , l'utilisation du javascript entraine qu'il faut ajouter un module qui permet de détecter si javascript est activé dans le navigateur auquel cas, il faut renvoyer un message. Tout ceci dans le but d'éviter d'avoir un message d'erreur????

Sinon, est-ce que vous préconisez :
l'utilisation un compteur sur le nombre d'essais de code avec temporisation de 5 minutes avant de recommencer?

Où de répondre à une question générée aléatoirement du style
qu'elle est le couleur de la voiture rouge de Mickey; qui apparement ne peut pas être interpreté par un robot alors qu'un code sur une image si?

[ABCIWEB]

Envoyé par hugodu28

Merci pour l'info,
sur GDS. J'ai lu se tuto
http://guillaume-affringue.developpe...?page=3#LIII-A
ça me parait bien qu'en penses-tu?

Oui c'est le principe, ensuite tu peux imaginer un mixte entre les différentes méthodes.

Envoyé par hugodu28

pour compléter , l'utilisation du javascript entraine qu'il faut ajouter un module qui permet de détecter si javascript est activé dans le navigateur auquel cas, il faut renvoyer un message. Tout ceci dans le but d'éviter d'avoir un message d'erreur????

C'est pour préciser d'où vient l'erreur. En même temps ce que tu appelle "module" peut se résumer à une ligne entourée des balises noscript :

Code :

1
2
3
<noscript>
Vous devez activer javascript pour l'authentification
</noscript>

[hugodu28]

ok bon cette fois-ci je pense être complet dans mon article.
comme précédement, je vais apporter les modifications et on verra ce que vous en pensez.
ABCIWEB j'essaye de te mettre des plus mais ça ne le prend pas; domage...

[ABCIWEB]

Envoyé par hugodu28

ABCIWEB j'essaye de te mettre des plus mais ça ne le prend pas; domage...

Encore une injustice
De mon côté j'ai essayé de te mettre +1 et ça a fonctionné

Sinon pour terminer sur le hash côté client, il faut avoir une lib javascript correspondante au hash que l'on veut mettre en place. Là encore la difficulté n'est pas grande puisque par exemple les mots clés "javascript sha" donnent les bonnes adresses dans un moteur de recherche

[hugodu28]

j'ai essayé le tuto sur le GDS. Le lien vers getGDS.zip est mort donc je peux pas finaliser le formulaire et tous les autres tuto sur le web are in english.
Quelqu'un a une idée?

De toute façon, le formulaire getGDS sert à determiner s'il y a un enregistrement=identifiant pour recopier le gds.

En l'état, sans le GDS, le formulaire sha1mdp.js sert à coder le mdp?
Si dans le formulaire pour tester le code, si je fais

Code :

 $mdp=($_post["sha1mdp"]+1)

ça équivau à un GDS

[ABCIWEB]

Envoyé par hugodu28

De toute façon, le formulaire getGDS sert à determiner s'il y a un enregistrement=identifiant pour recopier le gds.

Oui c'est une requête ajax standard qui rapatrie le gds correspondant au login en appelant la page gds.php. Si tu utilise jquery par ailleurs, cela simplifiera l'écriture de la requête ajax.

Mais il est important de ne pas se limiter à cette technique car le post envoyé est toujours identique. Cela protège ton mot de passe mais le fait d'envoyer le post hashé permettra une authentification. Pour éviter ce pb il faut combiner cette technique avec un gds par session. Le hash contenu dans le post ne doit être valide qu'une seule fois

[hugodu28]

j'essaye de mettre en place le GDS mais je rencontre des difficultées.
J'ai ouvert se post pour ne pas alourdir celui_ci.
si tu peux m'aider , merci

http://www.developpez.net/forums/d12...e/#post7067510

[hugodu28]

Je me pose une question par rapport à la pattern MVC.
La quasi totalité des articles sur le sujet font mention d'un contrôleur unique avec des fonctions appelées via un $GET.

Est-ce que si pour chaque fonction, je crée un formulaire.php,en appelant les différents modèles; du type:
verif_mdp.php; inserer.php; modifier.php; supprimer.php

ça revient au même?

Sinon, est-ce que l'on peu faire un truc du style
je poste $_POST['function']=verif_mdp (insert,modif,supp)

ET dans le contrôleur

Code :

1
2
3
4
5
 
if ($_POST['function']==verif_mdp] {.....}
if ($_POST['function']==insert] {.....}
if ($_POST['function']==modif] {.....}
if ($_POST['function']==supp {.....}

[ABCIWEB]

Un contrôleur unique c'est pour le principe et bien sur le papier. En réalité on fait souvent des "sous" contrôleurs, ou un contrôleur principal et des contrôleurs secondaires.
Pour ton formulaire tu auras un contrôleur secondaire qui vérifie si le formulaire est envoyé et en fonction de cela tu applique le modèle correspondant. En admettant qu'un champ témoin d'envoi du formulaire se nomme 'post_form_1', le contrôleur peut se résumer à :

Code :

1
2
3
4
if (isset($_POST['post_form_1'])) 
{
   include ('modele_post_form_1.php');
}

Le contrôleur principal qui dispatche les pages en fonction du choix utilisateur (donc qui gère effectivement des variables $_GET) aura pour tâche d'appeler la page incluant le code ci dessus (qui pourra être complété par d'autres contrôleurs si tu fais plusieurs actions dans cette page).