web-dev-qa-db-fra.com

Exploiter la fonction de redirection HTTP via l'en-tête Host

Je teste une application Web et j'ai trouvé une fonction de redirection qui semble peu sécurisée. Si je visite une page inexistante, je suis redirigé vers la page de connexion de l'application. Cependant, la fonction de redirection peut être exploitée en définissant un en-tête d'hôte personnalisé:

GET /temp/temp/nonexisting HTTP/1.1
Host: www.someevilsite.com

Le serveur qui répond avec:

HTTP/1.1 302 Found
...
location: www.someevilsite.com/login

Et me redirige simplement vers la page du mal. S'il est possible de falsifier l'en-tête de l'hôte d'un utilisateur distant et de le faire cliquer sur une URL personnalisée, l'utilisateur peut être redirigé vers une page malveillante et potentiellement se faire voler son mot de passe.

Cependant, je n'arrive pas à trouver un scénario dans lequel je puisse compromettre l'en-tête Host de l'utilisateur. Existe-t-il des moyens de manipuler l'en-tête Host de l'utilisateur, étant donné que le site Web est sur HTTP?

http
3
user1880405

C'est une vieille question, mais par souci d'exhaustivité, je vais ajouter quelques réflexions.

La référence en terme d'attaque des en-têtes d'hôtes est Attaques d'en-tête d'hôte pratiques (2013) et est toujours valide.

Les attaquants utiliseraient certainement l'astuce absolu-uri pour injecter le mauvais en-tête et être sûr d'atteindre le bon hôte virtuel. Mais dans certains cas, cela n'est même pas requis (comme cela peut être dans votre application actuelle, où toute demande avec un en-tête Host est acceptée étant donné que le HTTP la requête est faite sur la bonne IP)

# instead of
  GET /uri HTTP/1.1
  Host: good.name.com
# they would use
  GET http://good.name.com/uri HTTP/1.1
  Host: evil.com

Et cela pourrait être exploité principalement de 3 façons (principalement, mais c'est ouvert à plus d'idées):

  • empoisonnement du cache : si votre application alimente la page avec un domaine extrait de la demande (lors de la reconstruction des URL absolues en liens HTML), il y a peut-être une chance que ces les mauvais domaines se terminent dans la version en cache de la page pour /uri. Assez difficile à réaliser (le cache peut finir par mettre en cache la page en tant que http://good.name.com/uri et pas /uri.
  • mauvais liens dans les e-mails : supposons que votre application envoie un lien unique de réinitialisation de mot de passe, avec l'URL tirée de l'en-tête de l'hôte, alors l'attaquant pourrait espérer que quelqu'un clique sur le lien avec le domaine evil.com. Mais cela signifie que quelqu'un clique sur un lien e-mail de réinitialisation du mot de passe sans demander de réinitialisation du mot de passe (car l'attaquant a effectué la mauvaise requête)
  • Injection CRLF , comme avec tous les en-têtes injectés, un objectif pourrait être d'obtenir une réponse où une très mauvaise entrée Host (contenant CRLF, ou %0a%D, c'est "\ r\n") serait réutilisé sans filtrage sur les en-têtes de réponse. Menant à l'injection d'en-têtes dans la réponse.

Comme l'a noté @Steffen Ullrich, il n'y a aucun moyen de conduire un utilisateur innocent à effectuer l'attaque (en particulier parce que le navigateur utilise la résolution DNS du nom d'hôte pour trouver l'IP du serveur Web). Donc la seule victime semble pour être l'attaquant . Mais de toute façon, la cible d'attaque est asynchrone. Ce n'est pas comme une attaque XSS, la cible n'est pas l'utilisateur qui reçoit la réponse. Dans l'empoisonnement du cache, c'est assez évident (la cible est le cache), dans le courrier électronique de réinitialisation du mot de passe est utilisé pour porter l'attaque à la victime, et dans l'injection CRLF, nous entrons le fractionnement de la réponse HTTP et Zone de contrebande HTTP , où les conséquences sont assez délicates, mais elles peuvent entraîner un empoisonnement du cache, un déni de service, un empoisonnement de socket, incomplet requêtes, etc. La cible est un proxy inverse, et l'attaque sera ensuite étendue à d'autres utilisateurs via ce proxy.

6
regilero

Vous ne pouvez pas envoyer d'en-tête d'hôte personnalisé à partir du navigateur, ce qui signifie que vous ne pouvez pas l'exploiter en utilisant un navigateur seul. Et, puisque HTTPS est utilisé, vous ne pouvez pas monter un homme dans l'attaque du milieu pour modifier l'en-tête Host d'une demande existante. Mais même si HTTPS ne serait pas utilisé, vous ne gagnez vraiment rien de nouveau en modifiant l'en-tête Host dans la demande, car en tant qu'homme au milieu, vous pouvez déjà modifier l'en-tête Location dans la réponse de toute façon.

En résumé, je doute que le problème que vous avez trouvé puisse être utilisé pour quelque chose de malveillant, du moins pas lorsque vous utilisez le navigateur en tant que client.

5
Steffen Ullrich