Discussion :

[randriano]

Bonjour,

Le backoffice d'un site web n'est pas du tout à l'abri de ses anciens développeurs (virés ou démissionnaires)!!!

La partie non publique (backoffice) d'un site web est en général à accès par login+motdepasse
Le soucis c'est que cet accès protège seulement l'accès des pages webs formulaires d'insertion/édition/suppression de données.
Il suffit de savoir les adresses correspondantes à l'action d'un formulaire (<forme action =) pour créer une page web locale pointant vers ces adresses pour pouvoir créer/modifier/supprimer les données du site.
De plus, les anciens développeurs du site pourront donc détruire le site à tout moment même si on change le mot de passe!!

Qu'en pensez-vous?

[notar]

bonjour,

Le soucis c'est que cet accès protège seulement l'accès des pages webs formulaires d'insertion/édition/suppression de données.

pourquoi? il suffit que toutes les pages (y compris les pages de traitement) du back-office soient protégées par session.

De plus, les anciens développeurs du site pourront donc détruire le site à tout moment même si on change le mot de passe!!

la première chose à faire est de changer les identifiants des accès au serveur.

[randriano]

Bien sûr que toutes les pages sont protégées par session! Là je ne cherche pas vraiment un moyen à bien protéger le backoffice mais des suggestions sont les bienvenues
En fait, j'ai remarqué que les développeurs font seulement vérification de la session sur l'affichage des pages du backoffice mais en oubli de mettre dans les fonctions PHP pointées par les actions de formulares

la première chose à faire est de changer les identifiants des accès au serveur.

C'est ça le soucis avec les anciens employés, ce sont eux qui ont écrit le site donc ils connaissent les failles

[notar]

En fait, j'ai remarqué que les développeurs font seulement vérification de la session sur l'affichage des pages du backoffice mais en oubli de mettre dans les fonctions PHP pointées par les actions de formulares

un formulaire ouvert à tous ne doit pointer que sur des trucs très simples, non sensibles (demande de renseignement, de contact, d'envoi de doc, ...).
pour le reste des forms, il est nécessaire que l'utilisateur se logue et là, si tous les fichiers du back-office ( y compris les fichiers de fonctions ) sont sécurisées, je vois pas le problème.

[randriano]

Oui mais souvent les protections par login ne s'appliquent qu'à l'affichage des pages du backoffice, c'est bien que tu ne fais jamais cette erreur (cet oubli) notar!

Le backoffice est souvent généré à travers des outils par exemple phpMaker: essayez de faire un backoffice avec ça, tu te logues, tu arrives à une formulaire, enregistrer la page web, rentre à la maison, connecte à Internet, ouvre la page enregistrée, remplir le formulaire, poster et ça marche, puisqu'il n'y a pas de test lors de la soumission seulement à l'affichage.

[notar]

je n'utilise pas d'EDI pour coder; juste NotePad++

[RunCodePhp]

Salut

Pour le backoffice, il serait mieux de le protéger par le couple htaccess + htpassword et non pas uniquement en session (même avec un .htaccess).
Je dirais que c'est le minimum.

Aussi, il serait mieux que le nom où ce trouve cette partie admin soit quelque peu tordu de façon à ce que seul les admins le connaissent pour pouvoir pointer dessus.
De même que cette partie admin peu aussi ne pas se trouver dans le même domaine que le FrontEnd, mais un sous domaine par exemple.

Le backoffice est souvent généré à travers des outils par exemple phpMaker

Souvent ? J'entends rarement parlé de phpMaker, mais bon. Est il si connu que ça ?
Le verrouillage du backoffice pour les CMS par exemple demandent de faire des manips du coté serveur (comme ci-dessus) qu'ils ne prévoient pas à l'installation, car il peu être difficile à automatiser (voir impossible), ils supposent que ce sera fait.

Faut peut être éplucher la doc de phpMaker pour voir qu'est ce qui est recommander coté sécurité.

[randriano]

De même que cette partie admin peu aussi ne pas se trouver dans le même domaine que le FrontEnd, mais un sous domaine par exemple.

Ça c'est futé!

La faille de sécurité n'est pas seulement à l'utilisation de phpmaker mais plus souvent pour les sites dont le backoffice est développé à la main (on n'utilise pas un CMS donc)

Un backoffice de type https:// (accès sécurisé) est-il aussi intéressant ou difficile à mettre en place?

[grunk]

Bonjour,


Le soucis c'est que cet accès protège seulement l'accès des pages webs formulaires d'insertion/édition/suppression de données.
Il suffit de savoir les adresses correspondantes à l'action d'un formulaire (<forme action =) pour créer une page web locale pointant vers ces adresses pour pouvoir créer/modifier/supprimer les données du site.
Qu'en pensez-vous?

Sans vouloir vexer personne ,j'en pense qu'un site dont les formulaires (ou requete ajax) sont attaquables avec une page locale ou distantes est un gruyère niveau sécurité et que des "pros" du développement devrait pas faire ce genre de chose (sauf oubli ponctuel, que l'on peut difficilement éviter)

Il est assez simple de protéger un formulaire avec un jeton de sécurité par exemple. Chaque page génère un jeton unique et aléatoire qui est enregistré en session. Au moment ou une page de traitement reçois des données , elle vérifie le jeton qui doit correspondre à celui généré par le formulaire qu'elle doit traiter. Si ce n'est pas le cas , ca veut dire que on essai de traiter des données de manière frauduleuse.

Pour ce qui est des accès directe via login/mdp c'est plus compliqué. Bien souvent on prend pas la peine de créer un compte par développeur et quand bien même on le fait , les mot de passe sont souvent partager entre collègue (genre on t'appelle en vacances parce que mr X veux son truc pour hier, que tu es le seul à avoir un compte et qui y'a pas moyen que tu fasses 600 bornes pour mr X ^^ ).
Mais en principe les mot de passe se change régulièrement (mais comme ça fait chier tout le monde personne ne le fait ^^ )

L'idéal étant tout de même de pas laisser partir des collaborateurs de mauvais poil. (Perso ca m'a jamais traversé l'esprit de revenir sur des backoffices auquels j'avais participé)

[randriano]

Merci grunk pour le lien sur le jeton de sécurité (tokens), c'est intéressant or il me semble qu'on n'en parle pas beaucoup!!!

[RunCodePhp]

Le backoffice d'un site web n'est pas du tout à l'abri de ses anciens développeurs (virés ou démissionnaires)!!!

Pour ce qui est des accès directe via login/mdp c'est plus compliqué

Oui et non, ça dépend.

En tout cas, le vrai fond du problème est là, c'est une histoire de mot de passe.
Je vais le répéter, mais avec un .htaccess + .htpasswrd, à ne pas confondre avec une identification basée sur les sessions, si on change le mot passe, l'ancien collaborateur ne pourra plus accéder au backoffice.
L'exemple que tu as donnée me semble totalement impossible avec ça.

Ceci dit, il faudra aussi, je dirais même surtout dans le cas que tu évoque, changer l'accès à son Panel Administration de l'espace d'hébergement, sinon la manip ci-dessus ne servira pas à grand chose.
Idem pour les mots de passe de l'accès FTP et de la Bdd aussi tant on y est.

Donc quand un Administrateur quitte le navire, faut prendre quelques précautions.
C'est casse bonbon, c'est clair.


Après, il y a les bons et mauvais codeurs, et là, ce n'est pas l'outil qui est en cause.

Un backoffice de type https:// (accès sécurisé) est-il aussi intéressant ou difficile à mettre en place?

Le https ne sert à rien ici à mon avis, c'est fait pour crypter les données qui circulent sur la toile, quelles ne soient en clair.
Ce n'est pas ça qui empêchera une identification par exemple.
C'est utile uniquement si les données échangées sont sensibles (N° CB par exemple).

[randriano]

Je vais le répéter, mais avec un .htaccess + .htpasswrd, à ne pas confondre avec une identification basée sur les sessions, si on change le mot passe, l'ancien collaborateur ne pourra plus accéder au backoffice.
L'exemple que tu as donnée me semble totalement impossible avec ça.

J'ai lu ceci :

Limiter l'accès par htaccess, htpasswd


Il est parfois nécessaire de protéger l’accès à un répertoire sur un serveur web (ex : répertoire d’administration, contenant des données sensibles) afin d’éviter que n’importe qui puisse y accéder.

Il y a différentes méthodes, ont peut avoir recourt à des langages comme le PHP, ASP, PERL …), mais la méthode la plus simple est d’utiliser le mécanisme de protection d’Apache.
C'est-à-dire effectuer une protection à l’aide des fichiers .htaccess et .htpasswd. On estime ici que l’on n’a pas accès au fichier de configuration http.conf, ce qui est le cas chez un fournisseur d’accès.

Le fichier .htaccess est un fichier texte contenant des commandes Apache.

Voici un exemple :


AuthUserFile /home/login/admin/.htpasswd
AuthGroupFile /dev/null
AuthName "Veuillez vous identifier"
AuthType Basic

<Limit GET POST>
require valid-user
</Limit>


Quelques explications :

AuthUserFile : c’est le nom et le chemin d’accès du fichier qui contiendra les noms des utilisateurs et les mots de passe associés. Ce chemin doit partir de la racine du site.

Ici, les mots de passe seront dans /home/login/admin/.htpasswd.

On peut, et il est même conseillé de choisir un autre nom que .htpasswd pour le fichier qui contiendra le couple utilisateur/mot de passe. Le point précédent le nom de fichier permettra de cacher (au sens Unix /linux du terme).
Il est également recommandé de mettre le fichier des mots de passe en dehors de l’arborescence du site si l’on en a la possibilité.

AuthGroupFile : permet de définir un droit d’accès à un groupe d’utilisateur. Cette solution n’est que rarement utilisée pour un site Web. Le reste du temps il pointe vers /dev/null. Il faut que cette ligne soit présente.

AuthName : c’est le texte qui apparaîtra dans la fenêtre demandant le mot de passe.

AuthType : L’authentification est en générale « basic ». Les mots de passe sont alors envoyés en clair sur le réseau. Pour sécuriser davantage l’accès, on peut utiliser la méthode d’authentification « digest » qui crypte les mots de passe en MD5 . Ce système n’est supporté que par certains navigateurs.

Limit : C’est ici qu’on va indiquer ce qui est autorisé et interdit dans le répertoire. Les commandes GET et POST indiquent la récupération de pages web et la réponse à certains formulaires. POST est utilisé pour autoriser l’upload de fichiers sous le protocole http

Require valid-user : accepte tous les utilisateurs qui ont un login : mot de passe dans .htpasswd.
Require herve jacques : limite l’accès à un ou plusieurs utilisateurs précis, ici herve et jacques. A noter que les utilisateurs sont séparés par des espaces.

Une fois le fichier .htaccess créé, il faut le placer dans le répertoire à protéger.
Maintenant il nous faut créer le fichier .htpasswd

Sous unix/linux il existe un l’utilitaire : htpasswd.

Voici un exemple d’utilisation :


htpasswd -c .htpasswd herve



après validation Linux vous demande un mot de passe, puis une deuxième fois pour confirmation.
Si l’on édite le fichier .htpasswd obtient une ligne du style :

herve3l0HLu5v6mOF

ce qui correspond au nom d’utilisateur (login) et son mot de passe crypté. Il y aura une ligne pour chaque utilisateur.

Si l’on n’a pas accès à l’utilitaire htpasswd, on peut se rendre sur l’un des deux sites suivant proposant le cryptage d’un mot de passe.

http://home.golden.net/generator/ (il génére le couple login/password)

http://www.ovh.net/cgi-bin/crypt.pl

le fichier .htpasswd étant terminé, il suffit de le mettre à ça place (celle définie dans le fichier .htaccess).

Mais je ne comprends pas le truc de .htpasswd, un autre mot de passe à saisir en plus du mot de passe session donc? Le soucis aussi c'est qu'en hébergement on n'a pas vraiment accès au chemin Linux non?
Est-ce que ça marchera pour test sur mon PC sous Wamp (Windows)

[grunk]

Mais je ne comprends pas le truc de .htpasswd, un autre mot de passe à saisir en plus du mot de passe session donc? Le soucis aussi c'est qu'en hébergement on n'a pas vraiment accès au chemin Linux non?
Est-ce que ça marchera pour test sur mon PC sous Wamp (Windows)

Sous windows pas de problème un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
AuthName "Identifiez vous" 
AuthType Basic 
AuthUserFile "c:\wamp\www\.htpasswd" 
<Limit GET> 
Require valid-user 
</Limit>

Doit marcher sans problème. Seul différence avec linux c'est qu'il me semble que sous windows les mot de passe doivent être en clair dans le htpasswd.

Pour les hébergement mutualiser linux tu dois être en mesure de trouver le chemin complet avec quelque chose comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

echo realpath(dirname(__FILE__));

[RunCodePhp]

Mais je ne comprends pas le truc de .htpasswd, un autre mot de passe à saisir en plus du mot de passe session donc?

Oui, tout à fait.
Pour exemple de mon coté, il y a donc une double identification, et les 2 ont des log/pass différents.
C'est "casse bonbon", mais c'est volontaire, par mesure de sécurité évidemment.
La 1ère (.htaccess/.htpassword) est la plus importante, c'est elle qui à pour but de verrouiller l'accès au BackEnd.
La 1ère redirigera automatiquement sur le login.php pour effectuer la 2ème qui initialisera l'identification en session, et qui définira le type (ou groupe) de personne : administrateur ou éditeur par exemple.

Aussi, lors de ces identifications, je ne tiens absolument pas compte de ce qui pourrait être transmis en GET ou POST (à part le log/pass), c'est à dire qu'une fois les 2 étapes effectuées, une redirection est effectuée sur la page d'accueil, sans plus.
Donc s'il y a des truc pas très zen, ils seront perdus de toute façon.

Mais encore, il n'y a pas de pont entre le frontEnd vers le BackEnd, pas l'ombre d'un lien et encore moins des trucs en jQuery ou autre.

Le BackEnd n'est pas dans le même domaine que le FrontEnd, mais à part dans un sous-domaine (mais ça j'ai déjà dis). C'est pas grand chose mais c'est une touche supplémentaire.

Et pour finir, et c'est valable aussi bien pour le FrontEnd et le BackEnd, j'évite au maximum de tout mettre dans les HOST, dans le www par exemple, mais en-dehors, (donc au même niveau que le www).
Ca concerne les fichiers configs, les classes, les fonctions, etc, etc.
Ca veux dire qu'on ne peu pas pointer sur ces fichiers via HTTP.
En faite, dans le www il ne devrait avoir que ceux qui demandent à être récupérés par des requêtes HTTP, tout le reste peut être mis ailleurs, en-dehors.

Voilà en gros comment j'ai fais mon truc, et je vois mal comment on pourrait accéder au BackOffice sans avoir les 2 login/pass.


Il y a un truc où je me suis jamais penché dessus, j'en sais rien comment ça pourrait se faire, c'est de pourvoir limiter le nombre de tentatives d'identification concernant la 1ère étape (les .ht*).
Je l'ai fait pour la 2ème, limiter à 4 tentatives.

[SirDarken]

Hum le sujet m'intéresse grandement ayant quelque backoffice, pour le moment je sécurise chaque page, en testant que les sessions (plusieurs variables), si on a pas l'identification je renvoie en index.

Ma question est-ce que cela suffit ? à vous lire je m'inquiète un peu.
En théorie je pensai être à l'abris d'appel distants, et même local sans être identifier, aprés le mot de passe est dans une bdd.

[ThomasR]

Toujours crypter les mots de passe, de préférence avec un grain de sel, non constant, et généré pour chaque utilisateur.

La protection par session est globalement très satisfaisante.

Concernant la protection des scripts, la remarque de RunCodePHP est judicieuse.