Comment les serveurs Web savent-ils si vous utilisez un accès direct aux adresses IP?

64

Certains serveurs Web, lorsqu'ils accèdent à l'aide de leur adresse IP, renvoient une erreur indiquant que l'accès direct à une adresse IP n'est pas autorisé.

Je me demande depuis quelque temps comment cela fonctionne. Je veux dire, le navigateur ne résout-il pas toujours l'adresse IP et s'y connecte-t-il? L '"accès direct aux adresses IP" ne fait-il pas que sauter le DNS? Comment le serveur distant sait- il que vous avez ignoré le DNS?

networking dns apache-http-server ip http Joseph A.
la source
2
Si je me souviens bien, ce qu'il avait vraiment demandé avait été ajouté très tôt au protocole http, afin de fournir des serveurs virtuels sur le même hôte réel.
JDługosz
3
C'est fondamentalement le même processus qui permet à un seul serveur de différencier différents hôtes virtuels. Le vrai serveur mappe une URL sur l'un de ses hôtes virtuels. De nombreux serveurs ne peuvent pas utiliser d'URL non mappée, que ce soit par leur conception ou par défaut.
Manngo
Vous pouvez ignorer le DNS, mais éviter cette erreur si vous créez une entrée dans votre fichier hôtes pour le nom de domaine en question. Votre navigateur recherchera le nom de domaine et l'inclura dans l'en-tête Host:, mais aucune requête DNS ne sera effectuée en raison de l'entrée du fichier hosts.
Monty Harder
La réponse à ce genre de questions est généralement, parce que vous leur avez dit .
Thomas

Réponses:

91

Pour répondre à votre question sur la façon dont il sait , cela a à voir avec ce que votre navigateur envoie au serveur.

Vous avez raison de dire que le système le résout toujours en une adresse IP, mais le navigateur envoie l'URL à laquelle vous avez tenté d'accéder dans l'en-tête HTTP.

Voici un exemple d'en-tête que j'ai trouvé en ligne, modifié pour donner l'impression que vous utilisiez Firefox sous Windows et saisi apple.comdans la barre d'adresse:

GET / HTTP/1.1
Host: apple.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

Voici à quoi ressemblerait l'en-tête si vous utilisiez son adresse IP:

GET / HTTP/1.1
Host: 17.142.160.59
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

Ces deux éléments seraient envoyés à la même adresse IP via un socket, mais le navigateur indique au serveur à quoi il a accédé.

Pourquoi? Parce que les serveurs Web avec la même adresse IP peuvent héberger plusieurs sites et donner des pages différentes pour chacun. Il ne peut pas distinguer qui veut quelle page par adresse IP car ils ont tous le même - mais il peut les distinguer par l'en-tête HTTP.

ijoint
la source
7
Ah, c'est beaucoup plus logique maintenant! Donc, fondamentalement, le navigateur envoie à l’IP l’en-tête avec l’adresse IP ou le domaine, et le site part de son hypothèse à cet égard. Alors vraiment, ces restrictions sont faciles à contourner?
Joseph A.
7
Ce n'est pas une restriction que vous contournez, c'est juste que vous ne jouez pas à la balle et que vous obtiendrez des résultats étranges.
iAdjunct
Ces requêtes HTTP correspondent à ce que vous obtiendriez si vous utilisiez un proxy. Sans proxy, l'information vient dans l'en- hosttête. Voir cet exemple .
0xFE
2
bytec0de: L'autre élément de cette opération est que les configurations de serveur Web seront souvent configurées en fonction du nom d'hôte. Le paquet IP spécifie l'adresse IP, le segment TCP spécifie le numéro de port et l'en-tête HTTP spécifie le nom d'hôte. Donc, généralement, les serveurs sont configurés pour dire "si le client / navigateur leur demande exemple.com, donnez-leur ceci". Ils peuvent être configurés pour répondre également aux adresses IP ou aux caractères génériques (répondre à n'importe quoi), mais de nombreuses personnes ne font que copier des exemples, et de nombreux exemples préexistants sont basés sur le nom de domaine fourni par le navigateur.
TOOGAM
14
@ bytec0de Ce n'est pas une restriction . C'est plus comme utiliser le bon numéro de téléphone, mais la mauvaise extension - vous avez appelé le bon bâtiment, mais pas la bonne personne. Et la raison de son introduction est également à peu près la même que pour les téléphones: elle vous permet d’héberger plusieurs sites distincts sur la même adresse IP (et le même port TCP). Par exemple, notre serveur de développement a hébergé des centaines de sites Web distincts en même temps, et de nombreuses solutions d'hébergement Web utilisent la même approche ("enregistrez un domaine, pointez-le sur notre adresse IP, nous nous occuperons du reste"). .
Luaan
21

Avec le protocole HTTP 1.1 (l'ancienne version HTTP 1.0 était obsolète depuis un certain temps, il est donc peu probable qu'elle soit utilisée par une version récente d'un navigateur), l'en- hosttête a été introduit. Pour HTTP 1.1, il s'agit d'une ligne d'en-tête obligatoire qui doit être émise par un navigateur . Le nom de domaine est inclus par le navigateur sur cette ligne, par exemple Host: example.com. Le serveur Web sait donc à quel site Web le navigateur veut accéder à partir de cette ligne. Comme un serveur Web peut prendre en charge des dizaines de sites Web, cette ligne est importante pour déterminer le site Web sur lequel réside la page demandée. En supposant que le navigateur souhaite accéder à la page d'accueil d'un site sur example.com, il envoie la ligne suivante au serveur lorsqu'il se connecte au serveur:

GET / HTTP/1.1

Cette ligne spécifie que le navigateur souhaite obtenir le document racine, c'est-à-dire "/" pour le site Web. Si vous vouliez accéder /somedir/testpage.html, GET /somedir/testpage.htmlserait dans la ligne "get". La ligne sera suivie de la ligne ci-dessous:

Host: example.com

Ainsi, si le serveur Web prend en charge les sites Web exemple.com, someothersite.com, yetanothersite.org, etc., il sait qu'il doit renvoyer la page principale de example.com. S'il n'obtient pas cette ligne ou si aucun nom de domaine n'y est répertorié Host, il ne sait pas quelle page d'accueil du site Web doit être renvoyée. Donc, il peut retourner un message d'erreur ou renvoyer la page d'accueil pour un site "par défaut" pour le serveur.

Vous pouvez émettre les mêmes commandes que le navigateur utilisant le protocole telnet , par exemple à telnet example.com 80partir d'une invite de shell Linux ou d'une fenêtre de terminal Apple OS X , pour se connecter au port HTTP par défaut, port 80 - voir la section Test de l'accès à un site Web à l'aide de PuTTY . faire ainsi avec PuTTY sur un système Windows.

point de lune
la source
3
Juste une remarque: l'en-tête de l'hôte était également utilisé dans HTTP 1.0, ce n'était simplement pas nécessaire . HTTP 1.1 a rendu le champ obligatoire. En pratique, de nombreux serveurs HTTP 1.0 ne fonctionnaient tout simplement pas si le navigateur n'envoyait pas l'en-tête de l'hôte (pour toutes les raisons évoquées ci-dessus), de sorte que la plupart des navigateurs l'envoyaient quand même.
Luaan
6

Cela est dû à l' Host:en-tête HTTP. Ceci est très utile pour héberger plusieurs sites sur la même adresse IP. Par exemple, http://www.k7dxs.net/ et http://www.philipgrimes.com/ sont tous deux sur la même adresse IP. Cependant, en raison de l'en- Host:tête, ils peuvent afficher deux sites différents.

Pour HTTPS, comme @Toothbrush l'a souligné, ils utilisent l'indication du nom du serveur TLS car l'en-tête de l'hôte fait partie de la demande chiffrée et le serveur ne sait pas quel certificat offrir sans cela.

Expérience amusante: obtenez des données de sabotage pour Firefox (je n'ai pas réussi à trouver un équivalent pour Chrome) et commencez à altérer. Ouvrez http://slipstation.com/ et modifiez l'en- Host:tête dans la requête pour devenir http://www.zombo.com/ . Vous verrez un site Web éventuellement familier où tout est possible.

Duncan X Simpson
la source
En fait, ces sites utilisent l’ indication du nom du serveur . Il n'y a aucun moyen de déterminer quel site afficher si les deux sites sont hébergés sur le même serveur via HTTPS sans SNI, car le serveur ne sait pas quel certificat utiliser.
Brosse à dents
Oh intéressant. Mon expérience fonctionnera-t-elle encore?
Duncan X Simpson
Oui, si vous trouvez deux sites hébergés sur la même adresse IP via HTTP.
Brosse à dents
Mais pas HTTPS est ce que je demandais.
Duncan X Simpson
Non, cela ne devrait pas fonctionner avec HTTPS. Si tel est le cas, il existe une vulnérabilité de sécurité sur le serveur Web.
Brosse à dents
5

Le serveur Web peut être configuré pour accepter uniquement les connexions à un domaine ou à un sous-domaine particulier. Il pourrait héberger plusieurs domaines.

Ce que le serveur Web fait quand une adresse IP directe est utilisée est configurable. Dans le cas d'Apache, il ira par défaut au premier vhost nommé sur les sites activés, qui sont triés par ordre alphabétique.

C’est la partie la plus pertinente de la documentation Apache que j’ai trouvée, après une recherche rapide:

https://httpd.apache.org/docs/current/vhosts/name-based.html

paradroïde
la source