Comments on Vulgarisation informatique : comment fonctionne le Web ?

Si j'ai bien compris, www.google.com est donc le nom d'une unique machine (il ne peut pas y avoir deux machines avec le même nom ?). Est-ce qu'on sait où se trouve physiquement cette machine ? Que se passe-t-il s'il y a une coupure de courant à l'endroit où elle se trouve, ou si elle est détruite physiquement ? Est-ce qu'une autre prendrait le relais ?

Qu'en est-il de la machine mail.google.com ? Est-ce que c'est une autre machine forcément ?

Merci pour ce billet pédagogique !

Tu ne parles pas de WebAssembly, qui aurait pu être mentionné comme alternative/extension au JavaScript.
Mais ton billet est déjà bien touffu… en parler est peut-être superflu.

Merci pour ce cours sur le web. Je ne sais pas encore si je le lirai en entier, j'ai lu aujourd'hui jusqu'à "le travail du serveur web" inclus. J'ai appris des choses dans la partie "un mot sur la résolution DNS". J'ai trouvé particulièrement intéressante la distinction entre résolution par le FAI et résolution personnelle, qui répond à des questions que je me suis déjà posées en ayant la flemme d'aller chercher les réponses.

Ce qui pourrait être intéressant à préciser, c'est que le HTML à l'origine de la page Web, tout le monde y a facilement accès et peut le voir (clic droit sur Firefox, par exemple).

Bonjour,

Merci pour cette entrée copieuse, j'ai appris plein de choses (que je vais me dépêcher d'oublier à 90% je suppose, malheureusement, espérons qu'il en restera quelque chose).

Je m'interroge sur cette phrase "Je ne sais pas comment on peut régler ce problème et mettre fin à cette situation où le Web ne connaît qu'une succession de monopoles au lieu d'un écosystème sain. (En tout cas cela réfute certaines théories économiques selon lesquelles le libre échange non régulé éviterait naturellement la constitution de monopoles de fait.)"

Un détail sémantique d'abord. C'est bizarre de parler de théories concernant "le libre échange non régulé" (concept de commerce international) alors que tu as manifestement en tête l'évolution de la concurrence sur des marchés. Il s'agit donc de théories issues de ce qu'on nomme "économie industrielle" ou "économie de la concurrence" -- en anglais "industrial organization" -- et pas du tout de commerce international ou de libre échange.

Plus fondamentalement j'aimerais savoir à quelles théories tu penses et que cette évolution "réfuterait". Pour ce que j'en sais, la plupart des modèles en IO prédisent au contraire, dans les secteurs numériques avec des forts effets de réseau, une tendance naturelle au monopole qu'il est très difficile de contrer. J'aimerais savoir à qui tu penses et qui serait "réfuté"…

@Cigaes: cette solution dépend d'une configuration du serveur (e.g. Apache) en amont, et je soupçonne que les développeurs de Django ont préféré une solution qui ne suppose rien de cette configuration (d'ailleurs, ces applications tournent parfois sur des serveurs cloud "PaaS" sur lesquels on n'a absolument pas la main).

Il semble par ailleurs (cf https://peps.python.org/pep-3333/#url-reconstruction) être recommandé dans WSGI de préférer le HTTP_HOST au SERVER_NAME… j'ignore pourquoi.

Par contre, j'ai délibérément choisi d'utiliser Alice et Bob dans mon exemple qui ne nécessitait que deux intervenants (et si j'avais utilisé Eve, on aurait pu me dire qu'il ne s'agissait pas d'un cas de "eavesdropping" et que j'aurais dû utiliser Mallory ou je ne sais qui…).

@Thomas : Dans la situation que vous décrivez, l'outil de réinitialisation de mot de passe devrait avoir déjà appris à quel hôte virtuel s'adresse la requête pour choisir quelle base de données de mots de passe interroger, et donc a l'information sous une forme avec autorité.

Plus généralement, le mode de fonctionnement normal d'un serveur avec hôtes virtuels, c'est de consulter le champ Host en premier pour déterminer la configuration à utiliser, puis consulter le chemin et seulement ensuite commencer à exécuter du code dynamique. Si c'est l'interface CGI qui est utilisée, le champ Host correspond à $HTTP_HOST, et il devrait servir uniquement au serveur au début pour choisir $SERVER_NAME. Après ça, ça devrait exclusivement être $SERVER_NAME qui est utilisé. La même chose s'applique à d'autres interfaces que CGI, juste avec du vocabulaire différent.

Donc quand je lis « Django uses the Host header provided by the client to construct URLs in certain cases », la seule réaction raisonnable est 🤦🚮.

Accessoirement, c'est Eve qui est malintentionnée, pas Alice.

J'aurais cependant une question complémentaire : sur des sites avec un fort traffic, comment fait-on pour gérer la charge (et, par exemple, en rediriger une partie vers d'autres serveurs) ? Merci d'avance !

Merci beaucoup pour cette explication très claire ! Elle m'a permis d'ordonner des bouts de choses que je savais, et de les compléter pour pouvoir faire des liens entre eux.

@Cigaes: vu que je décris un cas concret, je trouve qu'il aurait été intéressant de préciser en quoi ce cas précis serait problématique.

À défaut d'explications, cela ressemble plus pour moi à une instance de cette "tradition" qui veut que les "anciens" critiquent systématiquement tout outil s'ajoutant dans un écosystème qu'ils avaient l'habitude d'utiliser (une variante du "c'était mieux avant" ?)

@Thomas : Ils ont l'air conçus en dépit du bon sens et des considérations élémentaires de sécurité, ces « frameworks », je vais continuer à ne pas les utiliser.

@Apokrif: en général, le framework demande de définir une whitelist de valeurs autorisées pour le header "Host", et va vérifier au moment où il traite une requête que la valeur de "Host" est bien autorisée.

Une attaque classique consiste pour Alice (mal intentionnée) à demander un reset de mot de passe avec l'email de Bob (victime) sur le site example.com en précisant "Host: evildomain.com".
Le header "Host" étant utilisé pour générer un lien complet, ici https://evildomain.com/reset-password/<secret-reset-token>, qui va être envoyé par email à l'adresse de Bob.
Alice espère alors que Bob va cliquer sur ce lien sans faire gaffe, lui donnant le contrôle de son compte.

Voir par exemple
- pour Django (framework Python): https://docs.djangoproject.com/en/4.2/topics/security/#host-header-validation
- pour Play (framework Java/Scala): https://www.playframework.com/documentation/2.8.x/AllowedHostsFilter

@Thomas: "De fait, beaucoup de frameworks vont rejeter les requêtes qui envoient des "Host" non déclarés côté serveur, pour éviter des attaques par "Host header injection"."

Je ne comprends pas à quelle étape, et selon quels critères, se fait ce rejet ?

@Phil: Je pense que le plus gros "oubli" de la présentation de David, est la mention des frameworks JavaScript modernes comme React, Angular ou Vue.js.

Quoi qu'on en pense, ces frameworks sont aujourd'hui utilisés par la plupart des sites modernes.

Globalement, ils permettent de générer dynamiquement le contenu d'une page web en le couplant avec des données qu'ils manipulent.

Le développeur doit alors généralement écrire un "template" qui va définir comment générer du HTML en fonction de ces données, et du code JS qui va guider la façon dont les données sont récupérées (généralement via des requêtes vers un "backend") et manipulées (généralement en réaction à des actions utilisateurs).

En interne, ces frameworks fonctionnent en manipulant le DOM (https://en.wikipedia.org/wiki/Document_Object_Model) pour le faire ressembler à ce que décrit le template, mis à jour avec les données calculées.

Du point de vue du développeur, il faut reconnaître que dans certains ces c'est nettement plus simple d'écrire un programme JavaScript "réactif" en utilisant ces frameworks.

Cependant, ce mouvement pousse aussi à une complexification en terme de code et de gestions des dépendances du "frontend"…

C'est une bonne introduction. Je l'ai transmise à des gens qui ne sont pas familiers avec le sujet, mais je ne sais pas s'ils auront le courage de se lancer dans la lecture…

> Je suis d'avis que les navigateurs devraient prévoir un moyen de contourner le DNS et de dire contacter l'adresse IP suivante en lui affirmant qu'on la contacte sous le nom suivant même si, en fait, cela ne correspond pas à ce qui s'est passé.

De fait, beaucoup de frameworks vont rejeter les requêtes qui envoient des "Host" non déclarés côté serveur, pour éviter des attaques par "Host header injection".

Il y a justement des discussions sur le Web Integrity sur Hacker News aujourd'hui

https://news.ycombinator.com/item?id=36876301
https://news.ycombinator.com/item?id=36875226

Concernant ton article, il correspond à peu près à mes connaissances sur le sujet. Au passage, j'ai quand même l'impression d'avoir un train de retard sur les développements web plus récents. Au delà des aspects généraux que tu as évoqués, j'ai l'impression qu'il y a beaucoup de "savoir faire" qui n'est pas hyper bien documenté, notamment parce que les outils évoluent vite. Si je devais faire un site style Twitter, je ne saurais pas vraiment par où commencer pour la partie frontend. Et j'avoue que je trouve tout ça assez chiant et fastidieux.

Sinon un aspect que j'aimerais bien te voir approfondir, c'est toute la partie authentification. Comment on est passé de l'authentification du web de papa, aux systèmes modernes. Comment marche le SSO, les générateurs de token etc…

Merci pour l'article, j'ai lu avec intérêt la première partie et même si je n'ai moi même pas appris grand chose (et j'aurais plein d'idée de détails très intéressants pour moi à ajouter, mais qui bien sur le rendrait totalement indigeste, donc plutôt bravo pour la concision vu le sujet)

Une petite remarque quand même : vous dites que "un lien très haut placé dans un moteur de recherche est raisonnablement sûr" : ce n'est vrai que si le lecteur réussit (ou si un navigateur correctement configuré le fait pour lui) à ne pas lire les publicités. Il y a malheureusement régulièrement des exemples de liens dangereux arrivant avant les résultats légitime de cette façon.