È possibile eseguire uno sviluppo sicuro contro localhost a condizione che:

• la tua macchina sia configurata per risolvere localhost in un indirizzo di loopback (nota, è possibile cambiare il tuo file hosts per risolvere localhost in un indirizzo diverso )
• la tua macchina è configurata per instradare l'indirizzo di loopback tramite l'interfaccia di loopback (è possibile instradare indirizzi di loopback a un'interfaccia non di loopback)
• configuri la tua applicazione per ascoltare sull'indirizzo di loopback , non 0.0.0.0 (molti framework web ascoltano su 0.0.0.0 per impostazione predefinita, questo è probabilmente il motivo più comune per esporre inaspettatamente i servizi a una rete non affidabile durante lo sviluppo)
• se usi un proxy, il tuo browser è configurato per non instradare localhost / loopback attraverso il proxy

In altre parole, una configurazione di rete abbastanza tipica.

Inoltre, fai attenzione che il tuo server di database non sia vincolante a 0.0.0.0, in quanto ciò consentirà a chiunque sulla rete di connettersi direttamente al server del database. Probabilmente è meglio impostare una configurazione del firewall in modo da sapere esattamente su quali porte e indirizzi sono in ascolto i servizi locali.

Il collegamento che hai indicato è nel contesto di una CA pubblicamente attendibile che rilascia certificati con il nome "localhost". Ciò non è sicuro in quel contesto perché il destinatario di tale certificato può utilizzare il certificato per intercettare la comunicazione di qualcuno con alcune configurazioni di rete insolite. Quando hai il pieno controllo sulla configurazione della tua macchina e sai di non avere alcune strane configurazioni sulle tue macchine, l'interfaccia di loopback è sicura.

Innanzitutto, puoi utilizzare http://127.0.0.1 per bypassare la ricerca DNS.

In secondo luogo, puoi creare il tuo certificato CA autofirmato, creare un certificato per localhost e connettiti a https: // localhost in modo sicuro. Non è possibile che un utente malintenzionato intercetti quella connessione.

Di conseguenza, l'accesso a " https: // localhost", ad esempio, su un punto di accesso WiFi ostile ( come i tuoi bar) possono essere intercettati da un aggressore di rete e reindirizzati a un sito (o un certificato) di sua scelta.

Questo è vero nel contesto del thread di posta elettronica. Il thread di posta elettronica riguarda se qualcuno possa ottenere un certificato valido per localhost da una CA attendibile . Se fosse possibile, allora sì, qualcun altro potrebbe impersonare https: // localhost. Ma una CA pubblica non è autorizzata a emettere certificati per localhost ( Requisiti di base, sezione 7.1.4.2.1; vedi anche questa discussione sul tracker Let's Encrypt).

Poiché ciò non è possibile, la tua CA privata è l'unica di cui ti fidi che ha emesso un certificato localhost .

Se fai spesso questo tipo di cose, perché non prendi solo un router da viaggio?

Con un piccolo router da viaggio, puoi configurare la tua rete interna con il proprio SSID, aggiungere la crittografia e imposta una whitelist personalizzata in modo che solo i tuoi indirizzi MAC siano consentiti su di essa.

Se sviluppi in Docker, quando avvii la tua app web (in un contenitore Docker), il contenitore avrà il proprio indirizzo IP che potrebbe non essere accessibile dall'esterno. Ti accederai con un IP speciale, che solo tu puoi vedere, come assegnato da Docker, ad es. http://172.17.0.2:9000.

Se la tua app web è anche accessibile dall'interfaccia di rete fisica del tuo host dipende da come avvii il contenitore. Ad esempio, il comando docker run non si collegherà all'interfaccia host a meno che non utilizzi -p , - P o --expose opzioni.

Altri vantaggi:

• L'app è altrimenti isolata dal tuo sistema host.
• L'implementazione su altri sistemi è più riproducibile.

probabilmente non è un attacco MITM praticabile qui. Supponendo Ubuntu e Django, ci sono due grandi fattori che cospirano contro un aggressore:

• Gli host predefiniti di Ubuntu e la configurazione DNS risolveranno localhost utilizzando un'impostazione hardcoded. Non eseguirà nemmeno una query DNS. Puoi cambiare questo ... Ma non farlo invece :)

• Django si lega a 127.0.0.1:8000 per impostazione predefinita. Per mitM completamente te, l'attaccante dovrebbe intercettare il traffico servito da Django ma non ha accesso.

Detto questo, la sicurezza web è complicata. Potrebbero esserci cose che stai facendo che un utente malintenzionato potrebbe sfruttare per avere un qualche effetto su di te.

Le risorse esterne devono essere protette

Molti di noi incorporano terze parti , File ospitati dalla CDN. Jquery, Bootstrap, ecc. Se sono http: // o // (ricorda che il server di sviluppo non utilizza TLS), ciò potrebbe dare a un utente malintenzionato l'opportunità di MITM quei file e inserisci script in tempo reale nelle tue pagine.

Per il bene dello sviluppo locale lontano da una connessione Internet, potrebbe essere meglio su tutti i conti ospitare tutto da solo.

Tecniche di click-jack e iframe

Solo perché non possono accedere al tuo server locale, non significa che non possano dire al tuo browser di accedervi. La sicurezza cross origin (probabilmente) impedirà loro di eseguire operazioni direttamente con esso, ma potrebbero inserirla in un iframe. Questa è una sorta di clickjack inverso.

Per l'utente sembrerebbe semplicemente il tuo sito web. Potrebbero persino acquisire tutti gli URL alla loro estremità e inserirli nel frame. Se fosse un sito web pubblico, potrebbero anche capire cosa stavi facendo clic.

Ma ovviamente stai già utilizzando django-secure , vero? Lo consiglierei. Un'impostazione e inizierai a inviare le intestazioni X-Frame-Options: DENY con ogni richiesta Django. In alternativa c'è un'opzione incorporata in Django che fa lo stesso. Raccomando django-secure perché fa molto di più.

La tua sicurezza su una rete ostile è più di un server web

Probabilmente hai altri demoni in esecuzione, oltre a cose come PostgreSQL che stai usando per lo sviluppo. Potresti eseguire server SSH, server di condivisione di file, ecc. E se sei abituato a un ambiente domestico, potresti aver saltato la giornata con una sicurezza più debole per comodità.

la cosa più semplice da fare è bloccare tutto il traffico in entrata. Supponendo che tu non abbia una configurazione UFW esistente, è semplice come:

  sudo ufw enableudo ufw default deny incomingsudo ufw default allow outgoing  

Ciò manterrà i riavvii. Se torni a casa e vuoi accedere a qualcosa, puoi disattivarlo con sudo ufw disable o modificare l'impostazione predefinita e aprire esplicitamente determinate porte.

Se hai intenzione di andartene una porta SSH esposta, ho scritto un articolo su rafforzamento delle configurazioni SSH. A meno che tu non sia nella mensa della NSA, questo dovrebbe tenere la maggior parte delle persone fuori dal tuo sistema.

Il problema che sta descrivendo il forum è in realtà l'opposto di quello che ti preoccupa. Sei preoccupato che qualcun altro sulla rete possa vedere cosa viene servito su localhost. Quel problema è che stai cercando di vedere cosa viene servito su localhost e invece ti viene servita una pagina web dannosa da qualcun altro sulla rete.

Questo problema in realtà non è così difficile da impostare su. È successo per caso qui al lavoro. Produciamo apparecchiature e software di rete, quindi ci sono molte persone con vari livelli di esperienza che mettono le macchine in vari stati di sperimentazione sulla rete. Qualcuno ha accidentalmente impostato "localhost" come nome host, è stato registrato in Active Directory e servito a tutti in DNS.

In un bar, non sarebbe così difficile da notare, perché la tua webapp all'improvviso sarebbe invece un'altra pagina. Se stai utilizzando un certificato TLS, non avrebbe un certificato valido.

Se sei preoccupato per la perdita dei dettagli della tua webapp, blocca semplicemente le porte in entrata pertinenti sul tuo firewall esterno. Su Linux, dovresti fare qualcosa del genere:

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

Accedi al tuo sito con http (s): //127.0.0.1/, configura la tua app per ascoltare 127.0.0.1 solo e sei al sicuro. La crittografia non è necessaria in quanto non vi è alcuna possibilità per qualcuno all'esterno di ascoltare: nulla va al di fuori del tuo computer, la tua app sul tuo computer "parla" con il tuo browser sul tuo computer tramite un indirizzo che non può essere utilizzata al di fuori del tuo computer.

Puoi codificare, ospitare ed eseguire nel tuo browser nel cloud su https utilizzando l'ide Cloud9, un repository GitHub e Heroku. A meno che non sia installato un keylogger o qualcuno stia guardando il tuo schermo, nessuno in quella stanza può rilevare cosa stai facendo.