Nil Le 08/03/2013 à 17:04 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 ?
(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).
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…
<<< 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
Nil Le 09/03/2013 à 12:21 Et du coup, tu préconises quoi quand tu passes par un hébergeur externe ?
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 '
? 
(mais ça revient peu ou prou à la même chose que filtrer par extension).