Acquisizione della password immessa nella pagina Web - Sostituzione HTML [chiusa]

Question

Acquisizione della password immessa nella pagina Web - Sostituzione HTML [chiusa]

#1 da (0 voti)
#2 da (0 voti)

-5

Per un po 'ho documentato alcuni exploit (avevo paura di man-in-the-middle) e mi è venuta un'idea.

Quando un utente effettua una richiesta a un server, il browser potrebbe provare a utilizzare http perché il server potrebbe non supportare per impostazione predefinita https.

Tuttavia, questa richiesta viene inviata su LAN, quindi ogni PC può vederlo (magari con uno sniffer). Tuttavia, se il mio computer potesse rispondere rapidamente alla richiesta, magari con l'intestazione giusta che indica che la richiesta è autentica, il browser visualizza la mia pagina Web (e la lascia su HTTP non su HTTPS).

Ora se l'utente ha richiesto google.com/login , allora potrei fornire una pagina web con questa pagina caricata in un iframe e qualche evento di tastiera nel mio JS (sebbene Google non possa essere caricato in un iframe). Questo è fondamentalmente un keylogger.

Non può essere fatto? Sembrerebbe un attacco deforme di uomo in mezzo. Se è possibile, perché non ci sono persone che lo sfruttano? (Non ho mai sentito parlare di questo attacco da nessuna parte).

man-in-the-middle keyloggers sniffing

posta sergiu reznicencu 28.01.2017 - 19:21

fonte

2 risposte

Leggi altre domande sui tag man-in-the-middle keyloggers sniffing

Quanto può trovare la polizia su di me solo con il mio IP? Ho cliccato accidentalmente su un annuncio sul sito web di webmd su un Iphone. Qualche possibilità di malware? [chiuso]

score 0 · Answer 1

When an user makes a request to a server, the browser has no idea it's going to be encypted (the connection hasn't been extablished yet - in the first miliseconds at least).

L'utente non fa una richiesta al server, lo fa il browser. L'utente al massimo chiede al browser di connettersi a un sito specifico facendo clic su un collegamento o inserendo esplicitamente un URL nella barra di stato. Solo nel secondo caso può essere che non ci sia specifica specifica del protocollo fornita dall'utente (cioè www.example.com invece di https://www.example.com ) in modo che il browser debba indovinare se l'utente indica http://.. o https://.. . In questo caso assumerà% insignificante% co_de a meno che non sappia già meglio che http://.. debba essere usato al suo posto. Il browser potrebbe avere questa conoscenza dalla precedente connessione in cui esisteva un reindirizzamento permanente a HTTPS o un HSTS intestazione in una precedente risposta da il sito di destinazione che ha specificato che in futuro dovrebbe essere utilizzato solo HTTPS. Oppure il browser potrebbe contenere informazioni HSTS precaricate, nel qual caso non è necessaria alcuna visita precedente al sito specifico. Ad esempio, Firefox e Chrome sono forniti con HSTS precaricati per alcuni siti essenziali come google.com.

Pertanto, in tutti i casi è noto dall'URL prima di connettersi se è necessario utilizzare HTTP o HTTPS. L'unico problema è se l'utente ha inserito un URL parziale (senza specifica del protocollo) che il browser non ha ancora alcuna conoscenza del sito di destinazione e quindi potrebbe aver indovinato l'intenzione dell'utente sbagliato scegliendo HTTP invece di HTTPS. Pertanto, il browser potrebbe avere l'idea sbagliata del protocollo da utilizzare, ma è sbagliato affermare che il browser non ha idea di quale protocollo utilizzare. E se viene utilizzato HTTPS, un utente malintenzionato nella rete locale non può semplicemente rispondere con alcuni dati fasulli come si immagina a meno che l'autore dell'attacco non abbia un certificato valido per il sito di destinazione emesso da una CA attendibile. Ecco come funziona TLS.

score 0 · Answer 2

if my computer could quickly respond to the request, maybe with the right header indicating that the request is genuine, then the browser would display my webpage

Come immagini questo funzionamento? Il browser effettua una richiesta al server su una particolare porta di origine su un particolare IP. Se si invia un pacchetto al client su quella porta di origine, il browser non lo accetterà perché non viene dall'IP corretto. Ignorerà questo nuovo flusso di dati non richiesto.

Inoltre, i firewall tendono a bloccare questo tipo di traffico in entrata per impostazione predefinita (nessuna connessione in entrata, solo le risposte sullo stesso IP / porta / sequenza di streaming).

Affinché funzioni, la macchina deve essere quella a cui viene fatta la richiesta , ed è qui che entra in gioco MITM. Se sei il "gateway", allora quando il cliente invia una richiesta a Google, designa il gateway (tu) come l'hop successivo, quindi, quando si inviano i dati, verrà interpretato dal client come una connessione valida e verrà visualizzato ciò che si invia indietro. Ma lo spoofing ARP dovrebbe essere impostato prima della richiesta (non dopo) a causa dei tempi del protocollo ARP.

Quindi, no, non è possibile il modo in cui lo hai impostato. Le funzioni TCP / IP di base su NIC, OS e firewall impediscono che ciò accada.

Dai un'occhiata ai firewall "stateful" vs "stateless" e cosa li fa guardare agli "stati", per maggiori informazioni. Quando Marcus ha detto "non è così che funziona lo strato di trasporto", questo è ciò di cui stava parlando.