Come posso sviluppare in modo sicuro una webapp locale in un bar?

Lo sviluppo sicuro contro localhost può essere fatto a condizione:

• la tua macchina è configurata per risolvere localhost in un indirizzo di loopback (nota, è possibile modificare il 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 indirizzare gli indirizzi di loopback all'interfaccia non di loopback)
• si configura l'applicazione per l'ascolto sull'indirizzo di loopback, non su 0.0.0.0 (molti framework Web sono in ascolto su 0.0.0.0 per impostazione predefinita, questo è probabilmente il motivo più comune per l'esposizione imprevista di servizi a una rete non sicura durante lo sviluppo)
• se si utilizza un proxy, il browser è configurato per non instradare localhost / loopback tramite il proxy

In altre parole, una configurazione di rete abbastanza tipica.

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

Il collegamento che hai indicato è nel contesto di una CA pubblicamente affidabile che emette certificati con il nome "localhost". Ciò non è sicuro in questo 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 che non hai alcune configurazioni strane sulle tue macchine, l'interfaccia di loopback è sicura.

In primo luogo, puoi utilizzare il collegamento per aggirare la ricerca DNS.

In secondo luogo, è possibile creare il proprio certificato CA autofirmato, creare un certificato per localhost e connettersi al link in modo sicuro. Non c'è modo in cui un utente malintenzionato può intercettare quella connessione.

As a result, accessing "https://localhost", say, on a hostile WiFi access point (such as your coffee shops) can be intercepted by a network attacker and redirected to a site (or a certificate) of their choosing.

Questo è vero nel contesto del thread email. Il thread email indica se qualcuno potrebbe ottenere un certificato valido per localhost da una CA attendibile . Se ciò fosse possibile, allora sì, qualcun altro potrebbe impersonare il link . Ma una CA pubblica non è autorizzata a emettere certificati per localhost ( Requisiti di base , sezione 7.1.4.2.1; vedere 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 di localhost .

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

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

Se sviluppi in finestra mobile , quando avvii la tua app Web (in un contenitore Docker), il contenitore avrà il suo Indirizzo IP che potrebbe non essere accessibile dall'esterno. Dovresti accedervi 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 sull'interfaccia di rete fisica del tuo host dipende da come si avvia 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.
• La distribuzione su altri sistemi è più riproducibile.

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

• La configurazione predefinita di host e dns di Ubuntu risolverà localhost usando un'impostazione hardcoded. Non eseguirà nemmeno una query DNS. Puoi cambiare questo ... Ma non invece:)

• Django si collega a 127.0.0.1:8000 per impostazione predefinita. Per coinvolgerti completamente, l'utente malintenzionato 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 tipo di effetto su di te.

Le risorse esterne devono essere sicure

Molti di noi incorporano file ospitati da CDN di terze parti. Jquery, Bootstrap, ecc. Se questi 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 di inserire script live nelle tue pagine.

Per motivi di sviluppo locale, lontano da una connessione Internet, potrebbe essere meglio per tutti, solo per ospitare tu stesso tutte le cose.

Tecniche di click-jacking e iframe

Solo perché non possono accedere al server in esecuzione locale, non significa che non potrebbero dire al tuo browser di accedervi. La sicurezza delle origini incrociate (probabilmente) impedirà loro di fare le cose direttamente, ma potrebbero inserirle in un iframe. Questa è una specie di reverse-clickjack.

Per l'utente questo sembrerebbe solo il tuo sito web. Potrebbero anche catturare tutti gli URL alla loro estremità e inviarli al frame. Se si trattasse di un sito Web pubblico, potrebbero anche capire cosa stavi facendo clic.

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

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

Probabilmente hai altri demoni in esecuzione, oltre a cose come PostgreSQL che stai usando per lo sviluppo. È possibile che tu stia eseguendo server SSH, server di condivisione file, ecc. E se sei abituato a un ambiente domestico, potresti avere saltato il giorno della gamba andato con 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 enable
sudo ufw default deny incoming
sudo ufw default allow outgoing

Questo continuerà a riavviarsi. Se torni a casa e desideri accedere a qualcosa, puoi disattivarlo con sudo ufw disable o modificare l'impostazione predefinita e aprire determinate porte in modo esplicito.

Se hai intenzione di lasciare una porta SSH esposta, ho scritto un articolo su rafforzando le 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 il forum sta descrivendo è in realtà l'opposto rispetto a quello che ti preoccupa. Sei preoccupato che qualcun altro sulla rete sarà in grado di vedere cosa viene offerto su localhost. Quel problema stai provando a vedere cosa viene offerto su localhost e viene invece servita una pagina Web dannosa da parte di qualcun altro sulla rete.

Questo problema in realtà non è così difficile da configurare. Ho avuto successo per caso qui al lavoro. Realizziamo 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 una caffetteria, non sarebbe difficile da notare, perché la tua webapp sarebbe improvvisamente un'altra pagina. Se stai utilizzando un certificato TLS, non avrebbe un certificato valido.

Se sei preoccupato che i dettagli del tuo webapp perdano, basta bloccare le porte in entrata pertinenti sul 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à che qualcuno esterno ascolti: nulla va al di fuori del computer, l'app sul computer "parla" con il browser del computer tramite un indirizzo che non può essere utilizzato al di fuori del computer.

Ti suggerisco di codificare, ospitare ed eseguire nel tuo browser nel cloud su https usando Cloud9 ide, un repository GitHub e Heroku. A meno che non sia installato un keylogger o qualcuno guardi il tuo schermo, nessuno in quella stanza può rilevare quello che stai facendo. Ovviamente questa configurazione comporta una sanzione finanziaria.

PS: Secondo i voti negativi, c'è qualcosa che posso imparare. Sarei felice di sentirlo. Grazie.