Lorsqu'un navigateur envoie une requête à un serveur local, il attache des en-têtes supplémentaires, tels que les en-têtes host et origin, pour fournir des informations supplémentaires au serveur. Ces en-têtes jouent un rôle crucial pour assurer la sécurité et le bon fonctionnement des applications Web. Dans cette réponse, nous explorerons comment le navigateur attache ces en-têtes et discuterons de leur importance dans le contexte de la sécurité du serveur HTTP local.
L'en-tête d'hôte est un composant essentiel de la requête HTTP et est utilisé pour spécifier l'hôte cible auquel la requête est envoyée. Lors d'une requête auprès d'un serveur local, le navigateur inclut l'en-tête host pour indiquer le nom d'hôte ou l'adresse IP du serveur avec lequel il souhaite communiquer. Cela permet au serveur d'identifier la destination prévue de la demande. Par exemple, si un navigateur souhaite accéder à une page Web hébergée sur un serveur local avec l'adresse IP 192.168.0.1, il inclura l'en-tête d'hôte comme suit : « Hôte : 192.168.0.1 ». Le serveur utilise ensuite ces informations pour acheminer la demande vers la ressource appropriée.
L'en-tête origin, quant à lui, est un mécanisme de sécurité mis en œuvre par les navigateurs modernes pour se protéger contre les attaques multi-origines. Il spécifie l'origine à partir de laquelle la demande est effectuée, y compris le protocole, le nom d'hôte et le numéro de port. Le navigateur inclut automatiquement l'en-tête d'origine dans les requêtes adressées aux serveurs locaux pour garantir que le serveur peut vérifier la source de la requête. Par exemple, si une page Web hébergée sur « http://localhost:8080 » envoie une requête à un serveur local sur « http://localhost:3000 », le navigateur inclura l'en-tête d'origine comme suit : « Origin : http ://localhost:8080". Cela permet au serveur de valider que la demande provient d'une source attendue et aide à empêcher tout accès non autorisé aux ressources sensibles.
En plus des en-têtes host et origin, il existe d'autres en-têtes que les navigateurs peuvent attacher lorsqu'ils envoient des requêtes aux serveurs locaux. Par exemple, l'en-tête de l'agent utilisateur fournit des informations sur l'application client (c'est-à-dire le navigateur) qui effectue la requête. Cet en-tête aide le serveur à comprendre les capacités et les limites du client, lui permettant ainsi de fournir des réponses appropriées.
Il est important de noter que même si les navigateurs attachent ces en-têtes par défaut, ils peuvent également être modifiés ou supprimés par divers moyens. Cela peut être fait via des extensions de navigateur, des serveurs proxy ou en manipulant directement la requête à l'aide de techniques de programmation. Par conséquent, il est crucial que les administrateurs de serveurs mettent en œuvre des mesures de sécurité appropriées pour valider et nettoyer les demandes entrantes, quelle que soit la présence de ces en-têtes.
Lorsqu'un navigateur envoie une requête à un serveur local, il attache des en-têtes supplémentaires tels que les en-têtes host et origin. L'en-tête host spécifie l'hôte cible de la requête, tandis que l'en-tête origin permet de se protéger contre les attaques multi-origines. Ces en-têtes jouent un rôle essentiel pour assurer la sécurité et le bon fonctionnement des applications Web. Les administrateurs de serveur doivent connaître ces en-têtes et mettre en œuvre des mesures de sécurité appropriées pour valider et nettoyer les demandes entrantes.
D'autres questions et réponses récentes concernant Principes fondamentaux de la sécurité des applications Web EITC/IS/WASF:
- Que sont les en-têtes de requête de récupération de métadonnées et comment peuvent-ils être utilisés pour différencier les requêtes de même origine des requêtes intersites ?
- Comment les types de confiance réduisent-ils la surface d'attaque des applications Web et simplifient-ils les révisions de sécurité ?
- Quel est le but de la stratégie par défaut dans les types approuvés et comment peut-elle être utilisée pour identifier les affectations de chaînes non sécurisées ?
- Quel est le processus de création d'un objet de types approuvés à l'aide de l'API des types approuvés ?
- Comment la directive sur les types de confiance dans une stratégie de sécurité de contenu aide-t-elle à atténuer les vulnérabilités de script intersite (XSS) basées sur DOM ?
- Que sont les types de confiance et comment corrigent-ils les vulnérabilités XSS basées sur DOM dans les applications Web ?
- Comment la politique de sécurité du contenu (CSP) peut-elle aider à atténuer les vulnérabilités de script intersite (XSS) ?
- Qu'est-ce que la falsification de requête intersite (CSRF) et comment peut-elle être exploitée par des attaquants ?
- Comment une vulnérabilité XSS dans une application Web compromet-elle les données utilisateur ?
- Quelles sont les deux principales classes de vulnérabilités couramment rencontrées dans les applications Web ?
Voir plus de questions et réponses dans EITC/IS/WASF Web Applications Security Fundamentals