Comment puis-je développer en toute sécurité une webapp locale dans un café?
Lorsque je développe une application Web, disons un site Django, je l'exécute localement et y accède généralement sur http: // localhost .
Je pensais que c'était intrinsèquement sûr parce que je supposais que localhost n'était accessible que localement. Cependant, j'ai découvert que même exécuter un serveur Web local (Apache, Nginx ...) avec un certificat HTTPS auto-signé n'aidera pas car localhost n'est pas vraiment nécessaire d'être local:
Lors de tests empiriques, nous avons vu plusieurs résolveurs ... envoyer des requêtes d'hôte local au réseau ... Par conséquent, accéder à " https: // localhost ", par exemple, sur un point d'accès WiFi hostile ( tels que 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. (Dans la chaîne de messagerie " Exception aux exigences de base, section 7.1.4.2.1 ".)
Si je développe une webapp, je dois l'exécuter localement et y accéder via un navigateur. Parfois, je dois le faire dans un café avec une connexion Internet. Quel point d'accès dois-je utiliser, sinon localhost?
Remarque
Certaines de mes applications de bureau s'exposent également via HTTP sur d'autres ports, par exemple http: // localhost: 90 . Je suppose que je ne devrais pas non plus y avoir accès dans un café?
Le développement en toute sécurité contre localhost peut être fait à condition:
- votre ordinateur est configuré pour résoudre localhost en une adresse de bouclage (notez qu'il est possible de changer votre fichier d'hôtes pour résoudre localhost en une adresse différente)
- votre machine est configurée pour router 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 sur l'adresse de bouclage, et non sur 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 fiable pendant le développement)
- si vous utilisez un proxy, votre navigateur est configuré pour ne pas router localhost/loopback via le proxy
En d'autres termes, une configuration réseau assez typique.
Veillez également à 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 que vous sachiez 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 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 de quelqu'un 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.
Tout d'abord, 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 vous connecter à https: // localhost en toute sécurité. Il n'y a aucun moyen qu'un attaquant puisse intercepter cette connexion.
Par conséquent, l'accès à " https: // localhost ", par exemple, sur un point d'accès WiFi hostile (comme vos cafés) peut être intercepté par un attaquant du réseau et redirigé vers un site (ou un certificat) de leur choix.
Cela est vrai dans le contexte du fil de discussion. Le fil de discussion consiste à savoir si quelqu'un pourrait 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 usurper l'identité 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 aussi cette discussion sur le tracker Let's Encrypt =).
Parce que ce n'est pas possible, votre propre autorité de certification privée est la seule à laquelle vous faites confiance qui a é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 chiffrement et configurer 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 que attribuée par Docker - par exemple http://172.17.0.2:9000.
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 conteneur. Par exemple, le docker run La commande ne se liera pas à l'interface hôte sauf si vous utilisez la commande -p, -P, ou --expose options .
Autres bénéfices:
- 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 probablement n'est pas une attaque MITM viable ici. En supposant Ubuntu et Django, il y a deux grands facteurs qui conspirent contre un attaquant:
La configuration par défaut des hôtes et du DNS d'Ubuntu résoudra
localhosten 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:8000par défaut. Pour vous pleinement MitM, l'attaquant devrait intercepter le trafic servi par Django mais ils n'y ont pas accès.
Cela dit, la sécurité Web est compliquée. Il y a peut-être des choses que vous faites qu'un attaquant pourrait exploiter pour avoir une sorte d'effet sur vous.
Les ressources externes doivent être sécurisées
Beaucoup d'entre nous intègrent des fichiers tiers 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 la possibilité de MITM ces fichiers et d'injecter un script en direct dans vos pages.
Dans un souci de développement local loin d'une connexion Internet, il peut être préférable à tous égards d'héberger tout ce que vous-même.
Techniques de détournement de clics et iframe
Ce n'est pas parce qu'ils ne peuvent pas accéder à votre serveur en cours d'exécution local qu'ils ne peuvent pas dire à votre navigateur d'y accéder. La sécurité de Cross Origin les empêchera (probablement) de faire des choses directement avec, mais ils pourraient le coller dans un iframe. Il s'agit en quelque sorte d'un clickjack inversé.
Pour l'utilisateur, cela ressemblerait à votre site Web. Ils pourraient même capturer toutes les URL à leur fin et les transmettre au cadre. S'il s'agissait d'un site Web public, ils pourraient également déterminer sur quoi vous cliquiez.
Mais bien sûr, vous utilisez déjà Django-secure , n'est-ce pas? Je le recommanderais. Un paramètre et vous commencerez à envoyer X-Frame-Options: DENY en-têtes avec chaque Django. Alternativement il y a ne option intégrée à Django qui fait de même. Je recommande Django-secure car il en 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, bien à côté 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 pouvez avoir jour de jambe sautée disparu avec une sécurité plus faible pour plus de commodité.
La chose la plus simple à faire est de bloquer tout le trafic entrant. En supposant que vous n'avez aucune configuration UFW existante, c'est aussi simple que:
Sudo ufw enable
Sudo ufw default deny incoming
Sudo ufw default allow outgoing
Cela persistera les redémarrages. Si vous rentrez chez vous et souhaitez accéder à quelque chose, vous pouvez le désactiver avec Sudo ufw disable ou modifiez la valeur par défaut et ouvrez certains ports explicitement.
Si vous allez laisser un port SSH exposé, j'ai écrit un article sur durcissement des configurations SSH . À moins que vous ne soyez dans la cantine NSA, cela devrait empêcher la plupart des gens d'entrer dans votre système.
Le problème que décrit le forum est en fait le contraire de ce qui vous inquiète. Vous craignez que quelqu'un d'autre sur le réseau puisse voir ce qui est servi sur l'hôte local. That le problème est que vous essayez de voir ce qui est servi sur localhost et à la place d'être servi par une autre page Web malveillante sur le réseau.
Ce problème n'est en fait pas si difficile à régler. Je l'ai fait arriver par accident ici au travail. Nous fabriquons des équipements de réseau et des logiciels, 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 niquement et vous êtes en sécurité. Le chiffrement n'est pas nécessaire car il n'y a aucune possibilité pour quelqu'un d'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 repo GitHub et Heroku. À moins qu'un enregistreur de frappe soit installé ou que quelqu'un regarde votre écran, personne dans cette pièce ne peut détecter ce que vous faites.