HTTP - Sécurité

HTTP est utilisé pour les communications sur Internet, les développeurs d'applications, les fournisseurs d'informations et les utilisateurs doivent donc être conscients des limites de sécurité de HTTP / 1.1. Cette discussion n'inclut pas de solutions définitives aux problèmes mentionnés ici, mais fait quelques suggestions pour réduire les risques de sécurité.

Fuite d'informations personnelles

Les clients HTTP ont souvent accès à une grande quantité d'informations personnelles telles que le nom de l'utilisateur, son emplacement, son adresse e-mail, ses mots de passe, ses clés de chiffrement, etc.

  • Toutes les informations confidentielles doivent être stockées sur le serveur sous forme cryptée.

  • La révélation de la version logicielle spécifique du serveur peut permettre à la machine serveur de devenir plus vulnérable aux attaques contre des logiciels connus pour contenir des failles de sécurité.

  • Les proxys qui servent de portail via un pare-feu réseau doivent prendre des précautions particulières concernant le transfert des informations d'en-tête qui identifient les hôtes derrière le pare-feu.

  • Les informations envoyées dans le champ `` De '' peuvent entrer en conflit avec les intérêts de confidentialité de l'utilisateur ou la politique de sécurité de son site, et par conséquent, elles ne doivent pas être transmises sans que l'utilisateur puisse désactiver, activer et modifier le contenu du champ.

  • Les clients ne doivent pas inclure de champ d'en-tête Referer dans une requête HTTP (non sécurisée), si la page de référence a été transférée avec un protocole sécurisé.

  • Les auteurs de services qui utilisent le protocole HTTP ne doivent pas utiliser de formulaires basés sur GET pour la soumission de données sensibles, car cela entraînera le codage des données dans Request-URI.

Attaque basée sur les noms de fichiers et de chemins

Le document doit être limité aux documents renvoyés par les requêtes HTTP pour être uniquement ceux qui ont été voulus par les administrateurs du serveur.

Par exemple, UNIX, Microsoft Windows et d'autres systèmes d'exploitation utilisent '..'comme composant de chemin pour indiquer un niveau de répertoire au-dessus du niveau actuel. Sur un tel système, un serveur HTTP DOIT interdire une telle construction dans Request-URI, s'il autorise autrement l'accès à une ressource en dehors de celles destinées à être accessibles via le serveur HTTP.

Usurpation DNS

Les clients utilisant HTTP dépendent fortement du service de noms de domaine et sont donc généralement sujets à des attaques de sécurité basées sur une mauvaise association délibérée d'adresses IP et de noms DNS. Les clients doivent donc être prudents lorsqu'ils supposent la validité continue d'une association numéro IP / nom DNS.

Si les clients HTTP mettent en cache les résultats des recherches de nom d'hôte afin d'améliorer les performances, ils doivent observer les informations TTL rapportées par le DNS. Si les clients HTTP ne respectent pas cette règle, ils pourraient être usurpés lorsque l'adresse IP d'un serveur précédemment accédé change.

En-têtes d'emplacement et usurpation d'identité

Si un serveur unique prend en charge plusieurs organisations qui ne se font pas confiance, il DOIT alors vérifier les valeurs des en-têtes Emplacement et Emplacement du contenu dans les réponses qui sont générées sous le contrôle desdites organisations pour s'assurer qu'elles n'essaient pas d'invalider les ressources sur dont ils n’ont aucune autorité.

Identifiants 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 à un serveur de demander aux clients de supprimer ces informations d'identification mises en cache, ce qui représente un risque majeur pour la sécurité.

Il existe un certain nombre de solutions pour résoudre ce problème et il est donc recommandé d'utiliser la protection par mot de passe dans les économiseurs d'écran, les délais d'inactivité et d'autres méthodes qui atténuent les problèmes de sécurité inhérents à ce problème.

Proxies et mise en cache

Les proxies HTTP sont des hommes du milieu et représentent une opportunité pour les attaques de type "man-in-the-middle". Les mandataires ont accès aux informations relatives à la sécurité, aux informations personnelles sur les utilisateurs individuels et les organisations, et aux informations exclusives appartenant aux utilisateurs et aux fournisseurs de contenu.

Les opérateurs proxy devraient protéger les systèmes sur lesquels les proxy fonctionnent, comme ils protégeraient tout système contenant ou transportant des informations sensibles.

Les proxys de mise en cache fournissent des vulnérabilités potentielles supplémentaires, car le contenu du cache représente une cible attrayante pour l'exploitation malveillante. Par conséquent, le contenu du cache doit être protégé en tant qu'informations sensibles.