Frage:
Wie kann ich eine lokale Webanwendung in einem Café sicher entwickeln?
lofidevops
2017-05-17 17:32:47 UTC
view on stackexchange narkive permalink

Wenn ich eine Webanwendung entwickle, beispielsweise eine Django-Site, führe ich sie lokal aus und greife normalerweise unter http: // localhost darauf zu.

Ich dachte, das wäre von Natur aus sicher, da ich davon ausgegangen bin, dass auf localhost nur lokal zugegriffen werden kann. Ich habe jedoch festgestellt, dass selbst das Ausführen eines lokalen Webservers (Apache, Nginx ...) mit einem selbstsignierten HTTPS-Zertifikat nicht hilft, da localhost nicht unbedingt lokal sein muss:

In empirischen Tests haben wir mehrere Resolver gesehen ... senden Sie Localhost-Anfragen an das Netzwerk ... Als Ergebnis des Zugriffs auf " https: // localhost", beispielsweise auf einem feindlichen WiFi-Zugangspunkt ( B. Ihre Coffeeshops) können von einem Netzwerkangreifer abgefangen und auf eine Site (oder ein Zertifikat) ihrer Wahl umgeleitet werden. (In der E-Mail-Kette " Ausnahme zu den Basisanforderungen, Abschnitt 7.1.4.2.1".)

Wenn ich eine Webanwendung entwickle, muss ich sie ausführen lokal und greifen Sie über einen Browser darauf zu. Manchmal muss ich das in einem Café mit Internetverbindung machen. Welchen Zugriffspunkt sollte ich verwenden, wenn nicht localhost?

Hinweis

Einige meiner Desktopanwendungen stellen sich auch über HTTP an anderen Ports zur Verfügung, z. B. http: // localhost: 9000. Vermutlich sollte ich auch in einem Café nicht darauf zugreifen?

Sie könnten möglicherweise eine virtuelle Maschine mit einem Netzwerk ausführen, das nur für den Host-Computer freigegeben ist. Sie müssten über die IP-Adresse auf Ihre Anwendung zugreifen (oder eine Hosts-Datei einrichten, um den namenbasierten Zugriff zu ermöglichen), der Code wird jedoch nicht verfügbar gemachtvorausgesetzt, die VM-Netzwerkkonfiguration ist korrekt.
Befürchten Sie, dass andere eine mögliche DNS-Abfrage an "localhost" vergiften und Ihre Verbindung abfangen, oder befürchten Sie, dass andere Benutzer Ihres WLANs selbst auf Ihren lokalen Server zugreifen?
@Arminius Diese Frage bezieht sich auf die erstere (mein sicherer Zugang zu meinem lokalen Host), ich werde die letztere für einen weiteren Tag verlassen!
Angenommen, localhost ist in Ihrer Hosts-Datei geschrieben, was wahrscheinlich der Fall ist, dann haben Sie kein Problem.
Lösen nicht alle gängigen Plattformen "localhost" standardmäßig standardmäßig in 127.0.0.1 oder :: 1 auf?Wie wäre jemand verletzlich?
Sie können einfach eine Netzwerkkarte auf Ihrem Computer trennen / deaktivieren, wenn Sie die eigentlichen Tests durchführen.Wenn Sie online gehen müssen, müssen Sie zuvor alle Testserver herunterfahren.
@AgentME Ja, das würden Sie denken.Die verknüpfte E-Mail argumentiert jedoch, dass dieses Verhalten nicht garantiert ist.
Um den Kommentaren von @Matthew's zu VMs nachzugehen, bieten sie Funktionen für sicheres Netzwerk.Beispielsweise verfügt VirtualBox über eine NIC-Option "Nur-Host-Netzwerk", mit der ein virtuelles LAN erstellt wird, das nur von Host und Gast gemeinsam genutzt wird.Sie können buchstäblich nur auf den anderen Computer zugreifen.
Ein etwas anderes Problem, aber Sie müssen sicherstellen, dass Ihr Webserver nur 127.0.0.1 und nicht 0.0.0.0 abhört, da er sonst öffentlich zugänglich ist.
Hätte ein öffentlicher WLAN-Spot nicht isolierte Kunden?
Kann nicht einfach eine Software-Firewall ausgeführt werden, die diesen Port von nicht lokalen Clients blockiert?
Acht antworten:
#1
+74
Lie Ryan
2017-05-17 18:57:12 UTC
view on stackexchange narkive permalink

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.

Dies ist zwar typisch, aber wahrscheinlich nicht die Standardeinstellung.Es könnte die Zeit von OP wert sein, einen anderen Computer mitzubringen und zu versuchen, auf seine App so zuzugreifen, wie er es nicht möchte.Testen - es ist ziemlich cool.
Stellen Sie für den Proxy-Teil sicher, dass Ihr System nicht so konfiguriert ist, dass Proxy-Einstellungen automatisch erkannt werden, da diese ein Proxy-Konfigurationsskript zurückgeben, mit dem Benutzer localhost ändern können
@LieRyan können Sie in Ihrer Antwort klarstellen, ob dies bedeutet, dass http gut genug ist, auch für Desktop-Apps, die eine Webschnittstelle bei localhost haben, oder ob https erforderlich / bevorzugt wird, danke!
@d3vid: unter der Annahme der typischen Netzwerkkonfiguration und der Tatsache, dass Ihr Computer noch nicht gefährdet ist, ist https für localhost service völlig überflüssig.Wie von Oli in einer anderen Antwort angesprochen, ist "https: // localhost" möglicherweise die einfachste Möglichkeit, HTTPS für schemarelevante Links (Links, die mit "//" beginnen) zu externen Ressourcen zu erzwingen, aber Sie können dies auch tunVerknüpfen Sie stattdessen einfach externe Ressourcen direkt mit der HTTPS-Version.
Der kritischste Rat hier ist die Bindung nur an Loopback, da dies das am häufigsten verletzte Element ist und das unerwartetste im Vergleich zur Entwicklung hinter einer NAT-Firewall für Endverbraucher.
Eine interessante Entwicklung (noch im Entwurf) https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-06
#2
+33
Sjoerd
2017-05-17 19:17:41 UTC
view on stackexchange narkive permalink

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 zu "localhost" navigieren, wird keine DNS-Suche durchgeführt.Es wird von der Hosts-Datei des Computers zurückgegeben.
@JeremiahMegel: Zumindest unter Linux ist das konfigurierbar (über `/ etc / nsswitch.conf`).Alle mir bekannten Linux-Distributionen enthalten jedoch eine Konfiguration, die wie von Ihnen beschrieben funktioniert.
Beachten Sie, dass [gültige Zertifikate für `localhost` in freier Wildbahn gesehen wurden] (https://www.eff.org/deeplinks/2011/04/unqualified-names-ssl-observatory).
@JeremiahMegel: Dies gilt weder allgemein für HOSTS-Dateien noch allgemein dafür, dass alle Maschinen über eine HOSTS-Datei verfügen.Obwohl diese Behauptungen seltsam klingen mögen, führen Sie für eine Weile eine kommerzielle Softwareentwicklung durch (in unserem Fall wird localhost verwendet), und Sie werden einige * wirklich * seltsame Betriebssystemkonfigurationen sehen.
MS Windows verwendet seit langem standardmäßig DNS, um localhost zu suchen.
Es gibt auch Probleme mit IPv4 vs IPv6 localhost, bei denen Windows sich nicht selbst finden kann.
Unterhaltsame Tatsache: Wenn Sie weniger eingeben möchten, funktioniert `http: // 127.1 /` genauso gut.
#3
+8
Dan Smith
2017-05-18 06:00:22 UTC
view on stackexchange narkive permalink

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 über WLAN sprechen, bin ich mir ziemlich sicher, dass das schnüffelig und fälschbar ist.
@RobertGrant Das hängt von der verwendeten Verschlüsselung ab.Die Details gehen weit über den Rahmen eines Kommentars hinaus, aber WPA2-PSK mit einem sicheren (komplexen) Schlüssel sollte für diese Verwendung sicher genug sein.Diese Lösung scheint jedoch umständlicher zu sein als softwarebasierte Lösungen.
Es ist etwas komplizierter als die Verwendung von Software, kann aber auch standardmäßig sicherer sein.Wenn d3vid nur seinen Laptop verwendet, kann er ihn auch einfach über Ethernet verbinden.Komplexer wird es nur, wenn Sie ein eigenes WLAN-Netzwerk einrichten möchten.
@DanSmith stimmte zu - wenn Sie verkabelt sprechen, ist es sicherer.Solange du ein Vorhängeschloss am Router hast :-)
#4
+5
z0r
2017-05-18 11:09:27 UTC
view on stackexchange narkive permalink

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.
Ich bevorzuge es, den Browser auch im Docker auszuführen.Alles kann (und sollte) dockerisiert werden.
#5
+5
Oli
2017-05-18 16:23:17 UTC
view on stackexchange narkive permalink

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.

tolle Tipps (und danke für die Ubuntu-Bestätigung)
#6
+2
Karl Bielefeldt
2017-05-19 23:05:21 UTC
view on stackexchange narkive permalink

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  
#7
+1
befree
2017-05-20 23:35:41 UTC
view on stackexchange narkive permalink

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.

#8
  0
Chris
2017-05-20 02:18:59 UTC
view on stackexchange narkive permalink

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.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...