1

Yellow !
Dans le cadre d'un projet que je veux pouvoir (re)déployer facilement, je me pose des questions de sécurité Apache :
Outre des fichiers classiques (PHP, js, css), le projet va contenir un certain nombre de fichiers XML (workflow, description des formulaires, correspondances formulaire-bases de données...) et des fichiers de logs spécifiques à cette application.
Je ne veux bien entendu pas que ces fichiers de logs puissent être accessibles à travers le service web. Mais je n'ai pas non plus envie qu'ils soient hors de l'arborescence de l'appli web (pour des facilités de configuration et de déploiement... quand on passe par un fournisseur de service d'hébergement web, on n'a pas accès à autre chose que /var/www [ou assimilé], par exemple), du coup je préfèrerais les avoir quelque part dans /var/www/monAppli
J'envisage de mettre en place un filtrage des accès par .htaccess pour refuser l'accès aux fichiers .xml et .log ; niveau sécurité, est-ce suffisant à votre avis ? Je me dis qu'en cas de problème avec Apache (.htaccess qui n'est plus pris en compte suite à une mise à jour, faille dans le service...), ça reste limite ; d'un autre côté, la criticité du contenu de ces fichiers est toute relative. Des conseils avisés ?

En passant, j'étends la question à la gestion des mots de passes utilisés dans les scripts PHP... vous faites comment ? Le bon sens voudrait qu'aucun mot de passe n'apparaisse dans les scripts en cas de défaillance du parseur ou d'Apache, et que les fichiers de mots de passes soient hors de /var/www ; en pratique, je ne l'a quasi jamais vu (c'est un coup à perdre ses mots de passes si on sauve /var/www et qu'on oublie de sauvegarder la localisation des mdp, sans compter le problème déjà soulevé des fournisseurs d'hébergement web). Vous faites comment ? Et la méthode du .htacces, comme proposée au début, vous en pensez quoi ?
avatar

2

ma réponse ne te sera pas utile grin

vire apache et utilise nginx, le contenu des .htaccess est directement dans la configuration du vhost, tu pourra également faire des regex sur les requêtes pour d'une seule ligne dégager tout ce qui est xml ou autre
et la le mec il le pécho par le bras et il lui dit '

3

En effet, je ne suis pas maître de l'architecture système, du coup ça ne m'intéresse pas vraiment cheeky
avatar

4

(Si tu as accès à la configuration du serveur au lieu de .htaccess c'est plus performant).

Sinon, le risque le plus élevé pour tes fichiers logs n'est pas un problème de apache, mais un problème de ton code php.
En dehors de ça, le .htaccess fonctionne bien, même s'il y a des erreurs qui peuvent survenir facilement, type :
=> suppression malencontreuse du .htacces
=> déconfiguration de apache par l'admin (genre désactivation du module php).
=> mauvaise vérification d'un chemin fourni par l'utilisateur dans ton php

Pour ce qui est des mots de passe, et de manière générale tout ce qui n'est pas supposé accessible aux utilisateurs (includes, conf, logs, …), une pratique courante est de les mettre dans un dossier interdit soit avec un .htaccess, soit avec la configuration du serveur. De cette manière, même si php était désactivé par erreur, ça resterait inaccessible (403 Forbidden de la part de Apache).

5

Nil (./1) :
Yellow !
Dans le cadre d'un projet que je veux pouvoir (re)déployer facilement, je me pose des questions de sécurité Apache :
Outre des fichiers classiques (PHP, js, css), le projet va contenir un certain nombre de fichiers XML (workflow, description des formulaires, correspondances formulaire-bases de données...) et des fichiers de logs spécifiques à cette application.
Je ne veux bien entendu pas que ces fichiers de logs puissent être accessibles à travers le service web. Mais je n'ai pas non plus envie qu'ils soient hors de l'arborescence de l'appli web (pour des facilités de configuration et de déploiement... quand on passe par un fournisseur de service d'hébergement web, on n'a pas accès à autre chose que /var/www [ou assimilé], par exemple), du coup je préfèrerais les avoir quelque part dans /var/www/monAppli
J'envisage de mettre en place un filtrage des accès par .htaccess pour refuser l'accès aux fichiers .xml et .log ; niveau sécurité, est-ce suffisant à votre avis ? Je me dis qu'en cas de problème avec Apache (.htaccess qui n'est plus pris en compte suite à une mise à jour, faille dans le service...), ça reste limite ; d'un autre côté, la criticité du contenu de ces fichiers est toute relative. Des conseils avisés ?

En passant, j'étends la question à la gestion des mots de passes utilisés dans les scripts PHP... vous faites comment ? Le bon sens voudrait qu'aucun mot de passe n'apparaisse dans les scripts en cas de défaillance du parseur ou d'Apache, et que les fichiers de mots de passes soient hors de /var/www ; en pratique, je ne l'a quasi jamais vu (c'est un coup à perdre ses mots de passes si on sauve /var/www et qu'on oublie de sauvegarder la localisation des mdp, sans compter le problème déjà soulevé des fournisseurs d'hébergement web). Vous faites comment ? Et la méthode du .htacces, comme proposée au début, vous en pensez quoi ?


Euh... comment dire... couic ?


Es-tu sûr de ne vraiment pas pouvoir découper en deux dossiers ? Effectivement, dans le pire des cas, tu peux mettre un .htaccess avec un
<Location /data>
Order allow, deny
Deny from all
Request no user
</Location>
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

6

Ah, si, bien sûr que je peux carrément filtrer tout un sous dossier oui (mais ça revient peu ou prou à la même chose que filtrer par extension).
avatar

7

Non. C'est bien plus sûr de filtrer tout le dossier (sans compter que le jour où tu voudras permettre de télécharger un fichier qui se termine par .log, tu vas faire sauter toutes tes protections).


Mais bon, ça reste quand même une très mauvaise idée…
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

8

Et du coup, tu préconises quoi quand tu passes par un hébergeur externe ?
avatar

9

en général avec l’hébergeur externe, la racine du ftp n'est pas le / du site mais le niveau du dessus

dans mon cas par exemple à la racine du ftp tu peut trouver les log d'erreurs et d’accès plus un répertoire "http" qui est le / du site, après à voir si tu à les droits en écriture sur la racine du ftp, pour y caller tes données

sinon, tu peut toujours foutre des noms de répertoire vachement balese pour y mettre tes log et dépendances

genre $path = './'.md5('hello').'/'.md5('world').'/';

peut être pas super conventionnel mais autant secure qu'un couple login / pass
et la le mec il le pécho par le bras et il lui dit '

10

Nil (./8) :
Et du coup, tu préconises quoi quand tu passes par un hébergeur externe ?

Je n'ai pas fréquenté beaucoup d'hébergeurs, mais à chaque fois il y avait la possibilité de définir la racine du site web (différente du FTP).

Accessoirement, les données à conserver devraient toujours être dans un dossier différent de celui du code, et la conf Apache qui ne pointe que vers un lien symbolique au lieu de donner directement sur le code. Comme ça, tu as juste un lien symbolique à changer quand tu mets à jour le code.
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant