Die sichere Entwicklung gegen localhost kann durchgeführt werden, sofern:

• Ihr Computer so konfiguriert ist, dass localhost in eine Loopback-Adresse aufgelöst wird (Hinweis: Sie können Ihre Hosts-Datei ändern, um localhost in eine andere Adresse aufzulösen )
• Ihr Computer ist so konfiguriert, dass die Loopback-Adresse über die Loopback-Schnittstelle weitergeleitet wird (es ist möglich, Loopback-Adressen an eine Nicht-Loopback-Schnittstelle weiterzuleiten).
• Sie konfigurieren Ihre Anwendung so, dass sie die Loopback-Adresse abhört , nicht 0.0.0.0 (viele Web-Frameworks hören standardmäßig 0.0.0.0 ab. Dies ist wahrscheinlich der häufigste Grund dafür, dass Dienste während der Entwicklung unerwartet einem nicht vertrauenswürdigen Netzwerk ausgesetzt werden.)
• Wenn Sie einen Proxy verwenden, ist dies Ihr Browser konfiguriert, um localhost / loopback nicht über den Proxy weiterzuleiten

Mit anderen Worten, eine ziemlich typische Netzwerkkonfiguration.

Achten Sie außerdem darauf, dass Ihr Datenbankserver nicht bindend ist auf 0.0.0.0, da dadurch jeder im Netzwerk eine direkte Verbindung zum Datenbankserver herstellen kann. Es ist wahrscheinlich am besten, eine Firewall-Konfiguration festzulegen, damit Sie genau wissen, welche Ports und Adressen die lokalen Dienste abhören.

Der Link, auf den Sie verwiesen haben, befindet sich im Kontext einer öffentlich vertrauenswürdigen Zertifizierungsstelle, die Zertifikate mit dem Namen "localhost" ausstellt. Dies ist in diesem Zusammenhang nicht sicher, da der Empfänger eines solchen Zertifikats das Zertifikat verwenden kann, um die Kommunikation einer Person mit ungewöhnlichen Netzwerkkonfigurationen abzufangen. Wenn Sie die volle Kontrolle über die Konfiguration Ihres eigenen Computers haben und wissen, dass Sie keine seltsamen Konfigurationen auf Ihren Computern haben, ist die Loopback-Schnittstelle sicher.

Erstens können Sie http://127.0.0.1 verwenden, um die DNS-Suche zu umgehen.

Zweitens können Sie Ihr eigenes selbstsigniertes CA-Zertifikat erstellen Zertifikat für localhost und sichere Verbindung zu https: // localhost. Ein Angreifer kann diese Verbindung auf keinen Fall abfangen.

Der Zugriff auf " https: // localhost" erfolgt beispielsweise über einen feindlichen WLAN-Zugangspunkt ( B. Ihre Coffeeshops) können von einem Netzwerkangreifer abgefangen und auf eine Site (oder ein Zertifikat) ihrer Wahl umgeleitet werden.

Dies gilt im Kontext des E-Mail-Threads. Im E-Mail-Thread geht es darum, ob jemand von einer vertrauenswürdigen Zertifizierungsstelle ein gültiges Zertifikat für localhost erhalten kann. Wenn dies möglich wäre, könnte sich jemand anderes als https: // localhost ausgeben. Eine öffentliche Zertifizierungsstelle darf jedoch keine Zertifikate für localhost ausstellen ( Basisanforderungen, Abschnitt 7.1.4.2.1; siehe auch diese Diskussion zum Let's Encrypt-Tracker ).

Da dies nicht möglich ist, ist Ihre eigene private Zertifizierungsstelle die einzige, der Sie vertrauen, die ein localhost -Zertifikat ausgestellt hat.

Wenn Sie solche Dinge häufig tun, warum nicht einfach einen Reiserouter kaufen?

Mit einem kleinen Reiserouter können Sie Ihr eigenes internes Netzwerk mit einer eigenen SSID einrichten und Verschlüsselung hinzufügen und richten Sie eine angepasste Whitelist ein, sodass nur Ihre MAC-Adressen darauf zulässig sind.

Wenn Sie in Docker entwickeln, hat der Container beim Starten Ihrer Web-App (in einem Docker-Container) eine eigene IP-Adresse, auf die von außen möglicherweise nicht zugegriffen werden kann. Sie würden mit einer speziellen IP darauf zugreifen, die nur Sie sehen können, wie von Docker zugewiesen - z. http://172.17.0.2:9000.

Ob auf Ihre Webanwendung auch über die physische Netzwerkschnittstelle Ihres Hosts zugegriffen werden kann, hängt davon ab, wie Sie den Computer starten Container. Beispielsweise wird der Befehl Docker run nur dann an die Host-Schnittstelle gebunden, wenn Sie -p , - verwenden. P oder - Expose Optionen.

Weitere Vorteile:

• Die App ist ansonsten von Ihrer isoliert Hostsystem.
• Die Bereitstellung auf anderen Systemen ist reproduzierbarer.

Es gibt wahrscheinlich hier keinen praktikablen MITM-Angriff. Unter der Annahme von Ubuntu und Django gibt es zwei große Faktoren, die sich gegen einen Angreifer verschwören:

• Die Standard-Host- und DNS-Konfiguration von Ubuntu löst localhost mithilfe einer fest codierten Einstellung auf. Es wird nicht einmal eine DNS-Abfrage durchgeführt. Sie können dies ändern ... Aber nicht stattdessen :)

• Django bindet standardmäßig an 127.0.0.1:8000 . Um Sie vollständig zu unterstützen, müsste der Angreifer den von Django bereitgestellten Datenverkehr abfangen, hat jedoch keinen Zugriff.

Die Websicherheit ist jedoch kompliziert. Es kann Dinge geben, die ein Angreifer ausnutzt, um eine Auswirkung auf Sie zu haben.

Externe Ressourcen müssen sicher sein

Viele von uns binden Dritte ein , CDN-gehostete Dateien. Jquery, Bootstrap usw. Wenn dies http: // oder // ist (denken Sie daran, dass der Entwickler-Server kein TLS verwendet), kann dies einem Angreifer die Möglichkeit dazu geben MITM diese Dateien und fügen Sie Live-Skripte in Ihre Seiten ein.

Um die lokale Entwicklung außerhalb einer Internetverbindung zu gewährleisten, ist es in jeder Hinsicht am besten, alle Inhalte selbst zu hosten.

Click-Jacking- und Iframe-Techniken

Nur weil sie nicht auf Ihren lokal laufenden Server zugreifen können, heißt das nicht, dass sie Ihren Browser nicht anweisen können, darauf zuzugreifen. Cross Origin Origin Security wird sie (wahrscheinlich) davon abhalten, Dinge direkt damit zu tun, aber sie könnten es in einen Iframe stecken. Dies ist eine Art Reverse-Clickjack.

Für den Benutzer würde dies nur wie Ihre Website aussehen. Sie könnten sogar alle URLs an ihrem Ende erfassen und sie an den Frame weiterleiten. Wenn es eine öffentliche Website wäre, könnten sie auch herausfinden, auf was Sie geklickt haben.

Aber natürlich verwenden Sie bereits django-secure , nicht wahr? Ich würde es empfehlen. Bei einer Einstellung werden bei jeder Django-Anfrage X-Frame-Optionen: DENY -Header gesendet. Alternativ gibt es eine in Django integrierte Option, die dasselbe tut. Ich empfehle django-secure , weil es viel mehr kann.

Ihre Sicherheit in einem feindlichen Netzwerk ist mehr als ein Webserver.

Sie haben wahrscheinlich andere Dämonen ausgeführt, neben Dingen wie PostgreSQL, die Sie für die Entwicklung verwenden. Möglicherweise führen Sie SSH-Server, Filesharing-Server usw. aus. Wenn Sie an eine häusliche Umgebung gewöhnt sind, haben Sie möglicherweise den Bein-Tag s> übersprungen, um die Benutzerfreundlichkeit zu verbessern.

Die Am einfachsten ist es, den gesamten eingehenden Datenverkehr zu blockieren. Angenommen, Sie haben keine vorhandene UFW-Konfiguration, ist dies so einfach wie:

  Wenn Sie nach Hause kommen und auf etwas zugreifen möchten, können Sie es entweder mit  sudo ufw disable  deaktivieren oder die Standardeinstellung ändern und bestimmte Ports explizit öffnen.  
 Wenn Sie gehen möchten Da ein SSH-Port verfügbar ist, habe ich einen Artikel über  Härten von SSH-Konfigurationen geschrieben. Sofern Sie nicht in der NSA-Kantine sind, sollte dies die meisten Menschen von Ihrem System fernhalten. 

Das Problem, das das Forum beschreibt, ist eigentlich das Gegenteil von dem, worüber Sie sich Sorgen machen. Sie befürchten, dass jemand anderes im Netzwerk sehen kann, was auf localhost bereitgestellt wird. Dieses Problem besteht darin, dass Sie versuchen zu sehen, was auf localhost bereitgestellt wird, und stattdessen eine schädliche Webseite von einer anderen Person im Netzwerk bereitgestellt wird.

Dieses Problem ist eigentlich nicht so schwer zu beheben oben. Ich habe es zufällig hier bei der Arbeit passieren lassen. Wir stellen Netzwerkgeräte und -software her, daher gibt es viele Leute mit unterschiedlichen Erfahrungsstufen, die Maschinen in verschiedene Experimentierzustände im Netzwerk versetzen. Jemand hat versehentlich 'localhost' als Hostnamen festgelegt, es wurde in Active Directory registriert und für alle in DNS bereitgestellt.

In einem Café wäre das nicht so schwer zu bemerken, da Ihre Webanwendung wäre plötzlich stattdessen eine andere Seite. Wenn Sie ein TLS-Zertifikat verwenden, verfügt es nicht über ein gültiges Zertifikat.

Wenn Sie Bedenken haben, dass Ihre Webapp-Details verloren gehen, blockieren Sie einfach die relevanten eingehenden Ports in Ihrer externen Firewall. Unter Linux würden Sie ungefähr so ​​vorgehen:

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

Greifen Sie mit http (s): //127.0.0.1/ auf Ihre Site zu, konfigurieren Sie Ihre App so, dass sie nur 127.0.0.1 hört, und Sie sind sicher. Eine Verschlüsselung ist nicht erforderlich, da keine Möglichkeit besteht, dass jemand außerhalb zuhört: Außerhalb Ihres Computers wird nichts angezeigt. Ihre App auf Ihrem Computer "spricht" mit Ihrem Browser auf Ihrem Computer über eine Adresse, die außerhalb Ihres Computers nicht verwendet werden kann.

Mit Cloud9 ide, einem GitHub-Repo und Heroku können Sie in Ihrem Browser in der Cloud über https codieren, hosten und ausführen. Sofern kein Keylogger installiert ist oder jemand auf Ihren Bildschirm schaut, kann niemand in diesem Raum erkennen, was Sie tun.