Discussion :

[cormnsa]

Bonjour,

Actuellement, je fais une revue de mes pages PHP en ajoutant le cryptage des users et mot de passes des accès à ma base de données MySQL ou autre dans mon fichier de config.
Mais, je me pose la question... dois-je aussi crypter le nom d'hôte, voir d'autres données lié à la connexion à la database (schema, sid, port, ...)

Bav

[gabi7756]

Bonjour,
C'est une bonne initiative de revoir la sécurité de tes pages PHP et de crypter les mots de passe des utilisateurs.

Pour ce qui est de crypter le nom d'hôte, le schéma, le SID, le port et d'autres données liées à la connexion à la base de données, la réponse est généralement non. Ces informations ne sont pas sensibles dans le même sens que les noms d'utilisateur et les mots de passe, et leur cryptage ne ferait qu'ajouter une complexité inutile à ton code.

Met toutes tes datas dans ton fichier conf et le tour est joué

[cormnsa]

En fait, pour l'instant, mes fichiers de config sont dans le répertoire avec les page "public" mais, l'accès est protégé par un .htaccess qui empêche la lecture du fichier.
Je suppose que c'est suffisant !

[cavo789]

Bonjour

C'est une erreur de conception de mettre des fichiers "privés" (les données de connexion) dans le répertoire public.

Le jour où ton htaccess cessera de fonctionner, boum, tout est sur internet. C'est comme utiliser un cadenas à deux euros pour sécuriser ta maison.

[cormnsa]

OK...

bon alors, je suis pas su internet, je suis sur des serveurs web privé (localisé on-premier ou dans GCP)

J'ai lus qu'il était recommandé de mettre les fichiers de conf ailleurs que dans le répertoire "public", je veux bien, j'ai encore lus ce matin que l'on pouvais faire des fichiers ini que l'on pouvait mettre dans "/etc/httpd/...." mais je trouve pas d'exemples (j'ai pas beaucoup chercher non plus) où je peux créer un fichier basculewebdp.ini, le mettre dans /etc/httpd/....

et mettre dedans l'ensemble de mes paramètres lié à l'application, que cela soit le nom de l'application, les définitions de connexions à la base de données, des adresses email de supervision, ...


Je me demande si j'aurais pas plus simple de poser la question à chatGPT.

[cavo789]

Public est un dossier qui est lui, seul, accessible sur internet. La norme est de mettre les fichiers qui ne doivent pas être accessible un niveau au dessus càd dans le dossier parent.

Si tu as /var/www/public p.ex. Tout ce qui se trouve dans /var/wwww n'est pas accessible sur internet.

Tu peux donc avoir un fichier /var/www/config.php par exemple qui pourra être lu depuis /var/www/public/index.php de manière sécurisée.

[cormnsa]

La structure des répertoires n'est pas la structure standard proposée par apache (/var/www/ et /var/www/public)

[cormnsa]

Je me demande si ce serait pas plus simple que que je fasse un folder "apache" dans /home (droit : utilisateur apache) et dans ce répertoire, je crée un répertoire "conf" avec toutes les configs de chaque app. web que j'ai dev. Dans l'application, je ferais appel en absolu au bon fichier de configuration !

[cavo789]

Bonjour

Tu ne sembles pas très ouvert aux suggestions. Oui, un standard est bien de scinder son application et de tout mettre dans /var/www sauf l'unique partie accessible qui serait dans /var/www/public. Dans ce dernier folder, on retrouve le seul et unique point d'entrée (index.php) ainsi que ce qui doit être accessible publiquement (les scripts JS, les fichiers CSS, les images, d'éventuels fichiers à télécharger (pdf, ...)).

Le fichier public/index.php fait alors le rôle de point d'entrée et charge les autres scripts php qui se trouvent dans le dossier au-dessus (et donc /var/www) où on retrouve en vrac les librairies externes (vendor), le framework utilisé (p.ex. Laravel, Symfony, etc), les fichiers de configuration, etc.

Oui, ce que je décris est une norme de fait. Vois Laravel p.ex.

Ce que tu proposes est impossible techniquement : le user Linux utilisé pour exécuter le site web (disons que ce user se nomme www-data) ne peut pas, ne devrait jamais, avoir le droit d'aller consulter ton dossier /home/xxx; tu imagines le trou de sécurité ? Cela voudrait dire qu'un pirate qui pourrait infilter ton site depuis une page web (user www-data) pourrait se promener sur ton serveur ? Ouch.

Et, aussi, si tu mets tes fichiers de configuration "ailleurs", tu vas faire face à un vrai problème de gestion de ton projet : tu devras toujours veiller à 1. garder le code du projet quelque part et 2. aussi garder la configuration. Dans la proposition que je fais ci-dessus; tant le projet que la configuration se trouve dans le même dossier (/var/www).

Maintenant, pour sûr, tu fais comme tu le souhaites.

[cormnsa]

Le problème n'est pas d'être ouvert ou non au suggestion, c'est de calculé le fait de devoir revoir l'architecture de 3 serveurs web de l'entreprise sans que cela se voit et avec plus d'une dizaine d'application WEB dont certaines en Zend Framework et d'autres qui sont utilisé pour des communications en json.

Il faut changer la configuration du serveur web, changer les includes ou require dans les pages PHP et faire la copie des fichiers de conf (en les renommant) vers le nouvelle emplacement

Ici, je viens de faire une nouvelle structure pour l'un des trois :

Avant :
Document root:
/xxx/www

Après :
Document root:
/xxx/www/public
Emplacement des fichiers de configuration (contient 4 fichiers de configuration puisque 4 application web)
/xxx/www/conf
Emplacement de script php non WEB
/xxx/www/tools

C'était le plus petit des trois serveurs.

[cormnsa]

Je viens de faire le deuxième serveur... ce fût un peu plus chaud car appli web très utilisée en production !

15h58 : troisième serveur terminé

[cavo789]

Nettement mieux puisque tu as mis sous public ce qui doit l'être et au-dessus ce qui ne doit pas être public.

Pour info, si l'outil n'est pas un outil Web (en console donc je suppose), l'habitude est de le mettre dans le dossier /opt.

Zéro obligation bien sûr mais ainsi l'utilisateur www_data n'y aura jamais access et c'est très bien ainsi.