Le développement en toute sécurité contre localhost peut être effectué à condition:

• votre machine est configurée pour résoudre localhost en une adresse de bouclage (notez qu'il est possible de modifier votre fichier hosts pour résoudre localhost en une adresse différente )
• votre machine est configurée pour acheminer l'adresse de bouclage via l'interface de bouclage (il est possible de router les adresses de bouclage vers une interface sans bouclage)
• vous configurez votre application pour écouter l'adresse de bouclage , pas 0.0.0.0 (de nombreux frameworks Web écoutent sur 0.0.0.0 par défaut, c'est probablement la raison la plus courante pour exposer de manière inattendue des services à un réseau non approuvé pendant le développement)
• si vous utilisez un proxy, votre navigateur est configuré pour ne pas acheminer localhost / loopback via le proxy

En d'autres termes, une configuration réseau assez typique.

De plus, veillez à ce que votre serveur de base de données ne soit pas lié à 0.0.0.0, car cela permettra à quiconque sur le réseau de se connecter directement au serveur de base de données. Il est probablement préférable de définir une configuration de pare-feu afin de savoir exactement sur quels ports et adresses les services locaux écoutent.

Le lien que vous avez indiqué se trouve dans le contexte d'une autorité de certification de confiance publique émettant des certificats avec le nom "localhost". Cela n'est pas sûr dans ce contexte car le destinataire d'un tel certificat peut utiliser le certificat pour intercepter la communication d'une personne avec des configurations réseau inhabituelles. Lorsque vous avez un contrôle total sur la configuration de votre propre machine et que vous savez que vous n'avez pas de configurations étranges sur vos machines, l'interface de bouclage est sûre.

Premièrement, vous pouvez utiliser http://127.0.0.1 pour contourner la recherche DNS.

Deuxièmement, vous pouvez créer votre propre certificat CA auto-signé, créer un certificat pour localhost et connectez-vous à https: // localhost en toute sécurité. Il n'y a aucun moyen qu'un attaquant puisse intercepter cette connexion.

En conséquence, accéder à " https: // localhost", par exemple, sur un point d'accès WiFi hostile ( comme vos cafés) peuvent être interceptés par un attaquant du réseau et redirigés vers un site (ou un certificat) de leur choix.

Ceci est vrai dans le contexte du fil de discussion. Le fil de discussion concerne la question de savoir si quelqu'un peut obtenir un certificat valide pour localhost auprès d'une autorité de certification de confiance . Si cela était possible, alors oui, quelqu'un d'autre pourrait se faire passer pour https: // localhost. Mais une autorité de certification publique n'est pas autorisée à émettre des certificats pour localhost ( Exigences de base, section 7.1.4.2.1; voir également cette discussion sur le traqueur Let's Encrypt).

Parce que ce n'est pas possible, votre propre autorité de certification privée est la seule en qui vous avez confiance à avoir émis un certificat localhost .

Si vous faites souvent ce genre de choses, pourquoi ne pas simplement vous procurer un routeur de voyage?

Avec un petit routeur de voyage, vous pouvez configurer votre propre réseau interne avec son propre SSID, ajouter un cryptage et configurez une liste blanche personnalisée afin que seules vos adresses MAC y soient autorisées.

Si vous développez dans Docker, alors lorsque vous démarrez votre application Web (dans un conteneur Docker), le conteneur aura sa propre adresse IP qui peut ne pas être accessible de l'extérieur. Vous y accéderiez avec une adresse IP spéciale, que vous seul pouvez voir, telle qu'attribuée par Docker - par ex. http://172.17.0.2:9000.

Le fait que votre application Web soit également accessible sur l'interface réseau physique de votre hôte dépend de la façon dont vous démarrez le récipient. Par exemple, la commande docker run ne se liera pas à l'interface hôte à moins que vous n'utilisiez -p , - P ou --expose options.

Autres avantages:

• L'application est par ailleurs isolée de votre système hôte.
• Le déploiement sur d’autres systèmes est plus reproductible.

Il n'y a probablement pas d'attaque MITM viable ici. En supposant Ubuntu et Django, il y a deux grands facteurs qui conspirent contre un attaquant:

• Les hôtes par défaut d'Ubuntu et la configuration DNS résoudront localhost en utilisant un paramètre codé en dur. Il n'effectuera même pas de requête DNS. Vous pouvez changer cela ... Mais ne le faites pas à la place :)

• Django se lie à 127.0.0.1:8000 par défaut. Pour vous MitM pleinement, l'attaquant aurait besoin d'intercepter le trafic servi par Django mais il n'y a pas accès.

Cela dit, la sécurité Web est compliquée. Il se peut qu'un attaquant puisse exploiter certaines choses que vous faites pour avoir un effet sur vous.

Les ressources externes doivent être sécurisées

Nous sommes nombreux à intégrer des tiers , Fichiers hébergés sur CDN. Jquery, Bootstrap, etc. S'il s'agit de http: // ou // (rappelez-vous que le serveur de développement n'utilise pas TLS), cela pourrait donner à un attaquant l'occasion de MITM ces fichiers et injecter un script en direct dans vos pages.

Pour le développement local loin d'une connexion Internet, il peut être préférable à tout point de vue d'héberger tout le contenu vous-même.

Techniques de prise de clic et iframe

Ce n'est pas parce qu'ils ne peuvent pas accéder à votre serveur local, qu'ils n'ont pas pu dire à votre navigateur d'y accéder. La sécurité d'origine croisée les empêchera (probablement) de faire des choses directement avec elle, mais ils pourraient la coller dans une iframe. C'est une sorte de détournement de clic.

Pour l'utilisateur, cela ressemblerait à votre site Web. Ils pourraient même capturer toutes les URL à leur extrémité et les transmettre au cadre. S'il s'agissait d'un site Web public, ils pourraient également déterminer sur quoi vous avez cliqué.

Mais bien sûr, vous utilisez déjà django-secure , n'est-ce pas? Je le recommande. Un paramètre et vous commencerez à envoyer des en-têtes X-Frame-Options: DENY avec chaque requête Django. Il existe également une option intégrée à Django qui fait la même chose. Je recommande django-secure car il fait beaucoup plus.

Votre sécurité sur un réseau hostile est plus qu'un serveur Web

Vous avez probablement d'autres démons en cours d'exécution, en plus de choses comme PostgreSQL que vous utilisez pour le développement. Vous utilisez peut-être des serveurs SSH, des serveurs de partage de fichiers, etc., et si vous êtes habitué à un environnement domestique, vous avez peut-être passé la journée avec une sécurité plus faible pour plus de commodité.

Le La chose la plus simple à faire est de bloquer tout le trafic entrant. En supposant que vous n'ayez aucune configuration UFW existante, c'est aussi simple que:

  sudo ufw enabledudo ufw default deny incomingsudo ufw default allow outgoing  

Cela persistera les redémarrages. Si vous rentrez chez vous et que vous voulez accéder à quelque chose, vous pouvez soit le désactiver avec sudo ufw disable soit changer la valeur par défaut et ouvrir certains ports explicitement.

Si vous allez quitter un port SSH exposé, j'ai écrit un article sur le durcissement des configurations SSH. Sauf si vous êtes dans la cantine NSA, cela devrait empêcher la plupart des gens d'entrer dans votre système.

Le problème décrit par le forum est en fait l'opposé de ce qui vous inquiète. Vous craignez que quelqu'un d'autre sur le réseau puisse voir ce qui est servi sur localhost. Ce problème est que vous essayez de voir ce qui est diffusé sur localhost et que vous recevez à la place une page Web malveillante par quelqu'un d'autre sur le réseau.

Ce problème n'est en fait pas si difficile à définir vers le haut. Je l'ai eu par accident ici au travail. Nous fabriquons des équipements et des logiciels de réseau, donc il y a beaucoup de gens avec différents niveaux d'expérience qui mettent des machines dans différents états d'expérimentation sur le réseau. Quelqu'un a accidentellement défini «localhost» comme nom d'hôte, il a été enregistré dans Active Directory et servi à tout le monde dans DNS.

Dans un café, ce ne serait pas si difficile à remarquer, car votre application Web serait soudainement une autre page à la place. Si vous utilisez un certificat TLS, il n'aurait pas de certificat valide.

Si vous craignez que les détails de votre application Web ne fuient, bloquez simplement les ports entrants pertinents sur votre pare-feu externe. Sous Linux, vous feriez quelque chose comme ceci:

  / sbin / iptables -A INPUT -o eth0 -p tcp --dport 80 -j DROP  

Accédez à votre site avec http (s): //127.0.0.1/, configurez votre application pour écouter 127.0.0.1 uniquement et vous êtes en sécurité. Le chiffrement n'est pas nécessaire car il n'y a aucune possibilité pour quelqu'un de l'extérieur d'écouter: rien ne sort de votre ordinateur, votre application sur votre ordinateur "parle" avec votre navigateur sur votre ordinateur via une adresse qui ne peut pas être utilisée en dehors de votre ordinateur.

Vous pouvez coder, héberger et exécuter dans votre navigateur dans le cloud via https en utilisant Cloud9 ide, un dépôt GitHub et Heroku. À moins qu'un keylogger ne soit installé ou que quelqu'un regarde votre écran, personne dans cette pièce ne peut détecter ce que vous faites.