Fichiers statiques et logs
Sécurité des fichiers statiques et des fichiers logs
Notions théoriques
1. Introduction
Les fichiers statiques (images, CSS, JavaScript) et les fichiers de logs sont des éléments essentiels d’un site Web ou d’un serveur.
Cependant, s’ils ne sont pas correctement protégés, ils peuvent exposer des informations sensibles ou être exploités par des attaquants.
Les fichiers statiques sont souvent stockés dans des répertoires accessibles publiquement (/assets/
, /static/
, /public/
).
Les fichiers de logs, en revanche, enregistrent des informations sur l’activité du serveur et des utilisateurs (access.log
, error.log
).
2. Risques liés aux fichiers statiques
Les fichiers statiques peuvent contenir des informations sensibles si leur accès n’est pas restreint :
- Fichiers de configuration exposés (
config.js
,.env
,settings.json
). - Fichiers de sauvegarde oubliés (
index.php.bak
,config.old
). - Fichiers contenant des commentaires ou du code non utilisé révélant des informations sur l’architecture du site.
Un attaquant peut scanner un site Web pour identifier ces fichiers et les exploiter.
3. Risques liés aux fichiers de logs
Les fichiers de logs enregistrent des informations qui peuvent être utiles pour la surveillance et le débogage, mais aussi pour les attaquants :
- Fuites d’informations sensibles (adresses IP, identifiants, erreurs détaillées).
- Injection de commandes si les logs ne sont pas correctement filtrés.
- Exploitation des logs pour des attaques XSS si les entrées utilisateur ne sont pas échappées.
Un attaquant peut essayer d’accéder aux fichiers de logs via des chemins connus (/var/log/apache2/access.log
, /logs/error.log
).
4. Bonnes pratiques de sécurisation
a) Protection des fichiers statiques
- Restreindre l’accès aux fichiers sensibles via
.htaccess
ou la configuration du serveur. - Ne pas stocker d’informations sensibles dans les fichiers statiques.
- Supprimer les fichiers inutilisés ou de sauvegarde.
b) Protection des fichiers de logs
- Définir des permissions strictes (
chmod 600
pour empêcher la lecture par des utilisateurs non autorisés). - Désactiver l’affichage des erreurs en production (
display_errors = Off
dansphp.ini
). - Limiter l’accès aux logs via un pare-feu ou une authentification.
Exemple pratique
Il est possible de sécuriser les fichiers statiques et les logs en appliquant des règles de configuration et des bonnes pratiques.
1. Protéger les fichiers statiques avec .htaccess
Un fichier .htaccess
peut être utilisé pour empêcher l’accès à certains fichiers :
# Bloquer l’accès aux fichiers de configuration
<FilesMatch "\.(env|json|bak|old|config)$">
Order allow,deny
Deny from all
</FilesMatch>
2. Restreindre l’accès aux fichiers de logs
Il est possible d’empêcher l’accès direct aux fichiers de logs en les déplaçant hors du répertoire public :
sudo mv /var/www/html/logs /var/logs_secure/
Puis, configurer Apache pour interdire l’accès :
<Directory "/var/www/html/logs">
Order allow,deny
Deny from all
</Directory>
3. Sécuriser les permissions des fichiers de logs
Il est important de restreindre les permissions des fichiers de logs :
chmod 600 /var/logs_secure/*.log
chown root:www-data /var/logs_secure/*.log
Test de mémorisation/compréhension
TP pour réfléchir et résoudre des problèmes
L’objectif de ce TP est de mettre en pratique les bonnes pratiques de sécurité pour protéger les fichiers statiques et les logs d’un site Web.
Étape 1 : Préparer l’environnement de travail
Avant de commencer, il est essentiel d’avoir un environnement fonctionnel.
Instructions :
- Créer un dossier de projet pour organiser les fichiers :
mkdir securite-Web
cd securite-Web
- Créer une arborescence de répertoires pour structurer les fichiers :
mkdir public logs_secure
- Créer des fichiers de test pour simuler un site Web :
touch public/index.html public/config.json logs_secure/access.log logs_secure/error.log
- Ajouter du contenu dans
public/index.html
:
<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="UTF-8">
<title>Site sécurisé</title>
</head>
<body>
<h1>Bienvenue sur le site sécurisé</h1>
</body>
</html>
- Ajouter du contenu dans
public/config.json
(fichier sensible) :
{
"database": {
"user": "admin",
"password": "supersecret"
}
}
- Ajouter des logs de test dans
logs_secure/access.log
:
echo "192.168.1.1 - - [14/Mar/2025:10:00:00 +0100] \"GET /index.html HTTP/1.1\" 200 -" > logs_secure/access.log
Vérifier si :
- Le projet est bien structuré avec un dossier
public/
pour les fichiers accessibles etlogs_secure/
pour les logs sécurisés. - Le fichier
config.json
contient des informations sensibles qui ne doivent pas être accessibles publiquement.
Étape 2 : Protéger les fichiers statiques sensibles
Certains fichiers statiques ne doivent pas être accessibles directement via un navigateur.
L’objectif est de bloquer l ’accès aux fichiers sensibles dans public/
.
Instructions :
- Créer un fichier
.htaccess
dans le dossierpublic/
:
touch public/.htaccess
- Éditer
public/.htaccess
et y ajouter les règles suivantes :
# Bloquer l'accès aux fichiers sensibles
<FilesMatch "\.(json|env|bak|old|config)$">
Order allow,deny
Deny from all
</FilesMatch>
- Tester la protection en démarrant un serveur local :
php -S localhost:8000 -t public
- Tenter d’accéder au fichier
config.json
via un navigateur :
http://localhost:8000/config.json
- Vérifier que l’accès est interdit (un message "403 Forbidden" doit s’afficher).
Vérifier si :
- L’accès aux fichiers
.json
,.env
,.bak
,.old
, et.config
est bloqué. - Une tentative d’accès à
config.json
retourne une erreur "403 Forbidden".
Étape 3 : Déplacer les fichiers de logs hors du répertoire public
Les fichiers de logs ne doivent jamais être accessibles via une URL.
L’objectif est de s’assurer qu’ils sont stockés dans un répertoire sécurisé.
Instructions :
- Vérifier l’emplacement actuel des logs :
ls -l public/
- Déplacer les logs vers
logs_secure/
:
mv public/*.log logs_secure/
- Modifier les permissions des fichiers de logs pour empêcher leur lecture par des utilisateurs non autorisés :
chmod 600 logs_secure/*.log
chown root:www-data logs_secure/*.log
- Configurer le serveur Apache pour interdire l’accès au dossier
logs_secure/
(si Apache est utilisé, éditer le fichier de configuration) :
<Directory "/var/www/securite-Web/logs_secure">
Order allow,deny
Deny from all
</Directory>
- Redémarrer Apache pour appliquer les modifications :
sudo systemctl restart apache2
- Vérifier que les logs ne sont plus accessibles via une URL :
http://localhost:8000/logs_secure/access.log
Vérifier si :
- Les fichiers de logs ne sont plus dans
public/
, empêchant leur accès via une URL. - Les permissions
chmod 600
garantissent que seuls les utilisateurs autorisés peuvent les lire.
Étape 4 : Désactiver l’affichage des erreurs PHP en production
Afficher les erreurs PHP dans un environnement de production peut révéler des informations sensibles.
L’objectif est de désactiver l’affichage des erreurs et d’enregistrer les logs de manière sécurisée.
Instructions :
- Ouvrir le fichier de configuration PHP (
php.ini
) :
sudo nano /etc/php/8.1/apache2/php.ini
- Rechercher et modifier les paramètres suivants :
display_errors = Off
log_errors = On
error_log = /var/logs_secure/php_errors.log
- Redémarrer Apache après modification :
sudo systemctl restart apache2
- Simuler une erreur PHP en ajoutant du code incorrect dans
public/index.php
:
<?php
echo $undefined_variable;
?>
- Vérifier que l’erreur n’apparaît pas dans le navigateur, mais est bien enregistrée dans
logs_secure/php_errors.log
:
cat logs_secure/php_errors.log
Vérifier si :
- L’affichage des erreurs PHP est désactivé (
display_errors = Off
). - Les erreurs sont enregistrées dans un fichier sécurisé et non visibles publiquement.
Étape 5 : Tester la sécurité et valider
L’objectif est de s’assurer que toutes les protections mises en place fonctionnent correctement.
Instructions :
-
Vérifier que les fichiers sensibles sont protégés :
- Tenter d’accéder à
config.json
via le navigateur. - Vérifier que l’accès est interdit.
- Tenter d’accéder à
-
Vérifier que les logs ne sont plus accessibles :
- Tenter d’accéder à
logs_secure/access.log
via l’URL. - Vérifier que l’accès est refusé.
- Tenter d’accéder à
-
Vérifier que les erreurs PHP ne sont pas affichées :
- Provoquer une erreur PHP et s’assurer qu’elle est enregistrée dans
logs_secure/php_errors.log
.
- Provoquer une erreur PHP et s’assurer qu’elle est enregistrée dans
-
Analyser le code et la configuration :
- Vérifier que
.htaccess
bloque bien les fichiers sensibles. - Vérifier que les permissions des fichiers sont correctes (
chmod 600
pour les logs).
- Vérifier que
Vérifier si :
- Tous les fichiers sensibles sont protégés et ne peuvent pas être consultés via une URL.
- Les logs sont stockés en dehors du répertoire public et ne sont accessibles qu’aux utilisateurs autorisés.
- Les erreurs PHP ne sont plus affichées publiquement, réduisant les risques d’exposition d’informations sensibles.
Conclusion
Ce TP a permis de mettre en œuvre des techniques essentielles pour sécuriser un site Web :
- Protéger les fichiers statiques sensibles avec
.htaccess
. - Déplacer les fichiers de logs hors du répertoire public.
- Restreindre les permissions des fichiers sensibles.
- Désactiver l’affichage des erreurs PHP en production.
Ces bonnes pratiques sont indispensables pour éviter les fuites d’informations et protéger un serveur contre les attaques potentielles.