Aller au contenu principal

15. Security Considerations (Considérations de Sécurité)

Cette section aborde les considérations de sécurité du protocole HTTP/1.1.

15.1 Personal Information (Informations Personnelles)​

Les clients HTTP ont généralement accès à une grande quantité d'informations personnelles (par exemple, le nom de l'utilisateur, l'emplacement, l'adresse e-mail, les mots de passe, les clés de chiffrement, etc.). Ces informations doivent être traitées avec précaution pour éviter toute divulgation accidentelle.

Principaux risques :

  • Les en-têtes User-Agent, Referer, From peuvent divulguer la vie privée de l'utilisateur
  • Les chaînes de requête dans les URI peuvent contenir des informations sensibles
  • Les fichiers journaux peuvent enregistrer des données sensibles

15.2 Abuse of Server Log Information (Abus d'Informations des Journaux Serveur)​

Les opérateurs de serveurs doivent être conscients que les fichiers journaux HTTP contiennent des informations personnelles des utilisateurs et doivent donc être protégés au même niveau que d'autres informations sensibles.

15.3 Transfer of Sensitive Information (Transfert d'Informations Sensibles)​

Comme tout protocole de transfert de données générique, HTTP ne peut pas réguler le contenu des données qu'il transmet, ni déterminer à l'avance la sensibilité d'une requête particulière.

Recommandations :

  • Utiliser HTTPS (HTTP over TLS/SSL) pour transférer des informations sensibles
  • Ne pas inclure d'informations sensibles dans les URI (peuvent être enregistrées)
  • Utiliser POST plutôt que GET pour soumettre des données de formulaire sensibles

15.4 Encoding Sensitive Information in URI's (Encodage d'Informations Sensibles dans les URI)​

Étant donné que la source des URI peut ne pas être fiable, les clients HTTP doivent être prudents lorsqu'ils incluent des données sensibles dans les URI. En particulier, lorsque les URI contiennent des mots de passe ou d'autres informations d'authentification.

15.5 Location Headers and Spoofing (En-têtes Location et Usurpation d'Identité)​

Si un seul serveur prend en charge plusieurs organisations, ce serveur doit vérifier les valeurs dans les en-têtes Location et Content-Location pour s'assurer qu'un attaquant ne peut pas utiliser le serveur pour générer des réponses qui semblent provenir d'une autre organisation.

15.6 Authentication Credentials (Informations d'Identification d'Authentification)​

Les clients HTTP et les agents utilisateurs existants conservent généralement les informations d'authentification indéfiniment. HTTP/1.1 ne fournit pas de méthode permettant au serveur d'origine d'indiquer au client de supprimer ces informations d'identification mises en cache.

Recommandations de sécurité :

  • Utiliser des mécanismes de délai d'expiration de session
  • Fournir une fonctionnalité de déconnexion explicite
  • Éviter de transmettre des informations d'identification dans les URI

15.7 Proxies and Caching (Proxies et Mise en Cache)​

Les proxies HTTP sont des intermédiaires qui peuvent présenter des risques de sécurité potentiels. Les organisations doivent considérer les implications en matière de confidentialité et de sécurité de l'accès via proxy.

Questions clés :

  • Les proxies peuvent voir toutes les données transmises
  • Les caches peuvent stocker des informations sensibles
  • Les journaux de proxy peuvent enregistrer l'activité des utilisateurs

Mesures de sécurité du cache :

  • Utiliser Cache-Control: private pour empêcher le cache partagé
  • Utiliser Cache-Control: no-store pour empêcher tout cache
  • Vérifier la configuration de sécurité du cache

15.8 DNS Spoofing (Usurpation DNS)​

Les clients HTTP dépendent du DNS pour résoudre les noms d'hôtes en adresses IP. Les attaques d'usurpation DNS peuvent amener les clients à se connecter au mauvais serveur.

Mesures de protection :

  • Utiliser DNSSEC pour vérifier les réponses DNS
  • Utiliser HTTPS pour assurer l'identité du serveur

15.9 Attacks Based On File and Path Names (Attaques Basées sur les Noms de Fichiers et de Chemins)​

Les implémentations doivent traiter Request-URI avec prudence pour empêcher les clients malveillants d'accéder à des ressources qui ne devraient pas être accessibles via HTTP.

Attaques courantes :

  • Attaques de traversée de chemin (../../../etc/passwd)
  • Accès à des fichiers spéciaux
  • Attaques par lien symbolique

Mesures de protection :

  • Normaliser tous les chemins
  • Limiter les répertoires accessibles
  • Vérifier les permissions de fichiers

Résumé​

La sécurité de HTTP/1.1 dépend de :

  1. Sécurité de la couche transport - Utiliser TLS/SSL (HTTPS)
  2. Implémentation correcte - Suivre les meilleures pratiques de sécurité
  3. Configuration appropriée - Limiter l'exposition des informations sensibles
  4. Sensibilisation des utilisateurs - Éduquer les utilisateurs pour identifier les risques de sécurité

Note importante : HTTP lui-même est un protocole sans état qui ne fournit pas de mécanismes de sécurité intégrés. La sécurité doit être mise en œuvre en utilisant HTTPS, des mécanismes d'authentification appropriés et des pratiques de codage sécurisées.

Dernière mise à jour le