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 dans php.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

Quel type de fichier peut contenir des informations sensibles s'il est accessible publiquement ?

Un fichier CSS

Un fichier .env

Un fichier HTML

Pourquoi les fichiers de logs peuvent-ils être dangereux s'ils sont mal protégés ?

Ils peuvent contenir des informations sensibles

Ils ralentissent le serveur

Ils empêchent l'accès aux fichiers statiques

Quelle directive Apache permet de bloquer l'accès à certains fichiers ?

<FilesMatch>

<RestrictFiles>

<BlockFiles>

Pourquoi faut-il restreindre les permissions des fichiers de logs ?

Pour empêcher leur modification

Pour éviter qu'ils deviennent trop volumineux

Pour empêcher un accès non autorisé

Quelle commande permet de changer les permissions d'un fichier sous Linux ?

chmod

chown

ls

Quelle configuration PHP doit être désactivée en production pour éviter les fuites d'informations ?

display_errors

error_reporting

log_errors

Quel est le risque principal d'un fichier de sauvegarde laissé sur un serveur ?

Il peut être téléchargé et exposer des informations sensibles

Il ralentit le site

Il empêche la mise en cache

Quel est l'intérêt de déplacer les fichiers de logs hors du répertoire public ?

Éviter qu'ils soient accessibles via une URL

Améliorer la vitesse du serveur

Faciliter leur suppression

Quel est le bon paramètre de permission pour un fichier de log sensible ?

600

777

644

Pourquoi ne faut-il pas stocker d'informations sensibles dans un fichier JavaScript public ?

Car il peut être lu par n'importe quel utilisateur

Car il ralentit le chargement de la page

Car il empêche l'exécution du code PHP

---

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 :

1. Créer un dossier de projet pour organiser les fichiers :

mkdir securite-Web
cd securite-Web

2. Créer une arborescence de répertoires pour structurer les fichiers :

mkdir public logs_secure

3. 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

4. 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>

5. Ajouter du contenu dans public/config.json (fichier sensible) :

{
    "database": {
        "user": "admin",
        "password": "supersecret"
    }
}

6. 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 et logs_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 :

1. Créer un fichier .htaccess dans le dossier public/ :

touch public/.htaccess

2. É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>

3. Tester la protection en démarrant un serveur local :

php -S localhost:8000 -t public

4. Tenter d’accéder au fichier config.json via un navigateur :

http://localhost:8000/config.json

5. 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 :

1. Vérifier l’emplacement actuel des logs :

ls -l public/

2. Déplacer les logs vers logs_secure/ :

mv public/*.log logs_secure/

3. 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

4. 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>

5. Redémarrer Apache pour appliquer les modifications :

sudo systemctl restart apache2

6. 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 :

1. Ouvrir le fichier de configuration PHP (php.ini) :

sudo nano /etc/php/8.1/apache2/php.ini

2. Rechercher et modifier les paramètres suivants :

display_errors = Off
log_errors = On
error_log = /var/logs_secure/php_errors.log

3. Redémarrer Apache après modification :

sudo systemctl restart apache2

4. Simuler une erreur PHP en ajoutant du code incorrect dans public/index.php :

<?php
echo $undefined_variable;
?>

5. 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 :

1. 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.

2. 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é.

3. 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.

4. 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 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.

attention

Ces bonnes pratiques sont indispensables pour éviter les fuites d’informations et protéger un serveur contre les attaques potentielles.