Come posso proteggere il mio sito web da bitsquatting?

Is there any standard defense technique against it?

Come delineato nelle altre risposte, gli errori di bit durante l'esecuzione di query sui nomi di dominio potrebbero non rappresentare una minaccia realistica per la tua applicazione web. Ma supponendo che lo siano, allora Integrità con subunità (SRI) aiuta.

Con l'SRI stai specificando un hash della risorsa che stai caricando in un attributo integrity , in questo modo:

<script src="http://www.example.org/script.js"integrity="sha256-DEC+zvj7g7TQNHduXs2G7b0IyOcJCTTBhRRzjoGi4Y4="
    crossorigin="anonymous">
</script>

D'ora in poi, non importa se lo script viene prelevato da un dominio diverso a causa di un errore di bit (o modificato da un MITM) perché il browser rifiuterà di eseguire lo script se l'hash del suo contenuto non lo fa t corrisponde al valore di integrità. Quindi, quando un errore di bit, o qualsiasi altra cosa, ha reso l'URL risolvibile con dxample.org controllato dall'aggressore, l'unico script che potevano iniettare con successo sarebbe stato quello corrispondente all'hash (cioè lo script che si intendeva caricare comunque).

Il caso d'uso principale per SRI è il recupero di script e fogli di stile da CDN potenzialmente non attendibili, ma funziona su qualsiasi scenario in cui si desidera garantire che la risorsa richiesta non sia modificata.

Tieni presente che l'SRI è limitato a script e link per ora, ma il supporto per altri tag potrebbe venire in seguito:

Note: A future revision of this specification is likely to include integrity support for all possible subresources, i.e., a, audio, embed, iframe, img, link, object, script, source, track, and video elements.

(Dalla specifica)

(vedi anche questo bug ticket)

La tua preoccupazione è molto probabilmente infondata.

Prima di tutto, devi capire quanto siano improbabili questi malfunzionamenti della memoria. La persona che ha scritto l'articolo precedente ha registrato richieste su 32 cloni di alcuni dei domini più visitati su Internet nel corso di 7 mesi. Quelle 52.317 visite dovevano essere tra centinaia di miliardi di richieste. A meno che non gestiate un sito Web sulla scala di Facebook, un utente malintenzionato dovrebbe essere estremamente fortunato ad avere anche solo una vittima sfortunata sul proprio dominio bitsquatting.

Quindi devi notare che gli errori di memoria causano diversi malfunzionamenti. L'autore scrive:

These requests [...] show signs of several bit errors.

Se il sistema della vittima è così rotto da non poter nemmeno inviare una richiesta HTTP senza diversi errori di bit, allora anche il malware che scaricano da esso probabilmente non verrà eseguito senza errori. È un miracolo che sia persino riuscito ad avviarsi in quella condizione.

Riguardo a quei casi in cui sono stati rilevati errori di bit in "cache di applicazioni Web, risolutori DNS e un server proxy" e quindi colpiscono più utenti (alcuni di loro forse abbastanza sfortunati da ottenere abbastanza malware in uno stato eseguibile): In queste situazioni, la risposta HTTP proviene da un server diverso da quello richiesto dal client. Pertanto, quando utilizzi solo HTTPS (che presumo tu faccia, o avresti degli attacchi ben più gravi di cui preoccuparti), la loro firma non verrà verificata e il browser non scaricherà tale risorsa.

Inoltre, HTTPS renderà molto meno probabile una connessione riuscita quando c'è un sistema con RAM interrotta sulla rotta. Un singolo bit-flip in un messaggio crittografato TLS impedirà l'estrazione dell'hash, quindi il destinatario la rifiuterà.

tl; dr: smetti di preoccuparti e imposta solo HTTPS.

Dubito dell'affidabilità dell'articolo. Mentre discusso in DEFCON e pubblicato come whitepaper, ho serie preoccupazioni riguardo ai risultati sperimentali.

Secondo il commento di @mootmoot, l'autore non è riuscito a determinare errori di programmazione deterministici da fluttuazioni casuali di bit.

La mia dichiarazione concernente è

During the logging period [Sept. 2010 / May 2011, ndr] there were a total of 52,317 bitsquat requests from 12,949 unique IP addresses

No, l'autore ha solo dimostrato che i suoi domini tozzi sono stati contattati, ma probabilmente non è riuscito a fornire ulteriori informazioni

1. Quale percentuale della rete CDN originale rappresenta quel traffico (ciò è verificabile in teoria, ma non ho quei dati)
2. Occorrenza di domini di riferimento di origine

Il secondo è molto importante perché aiuta a isolare i fallimenti programmatici deterministici dalla fluttuazione casuale dei bit.

Considera il seguente esempio: se trovi una voce in gbcdn.net (facebook squat) con il referer https://facebook.com probabilmente hai trovato un bitsquat.

Se al contrario trovi più voci da un sito web poco conosciuto che puoi ispezionare per trovare con un pulsante simile a quello rotto , il problema è probabilmente dovuto a un programmatore che non copia / incolla il codice correttamente, o anche un piccolo capovolgimento si è verificato nell'IDE del programmatore. Chi lo sa ...

Disclaimer : sono un dipendente di Emaze Networks S.p.A.

Un modo per difendersi da questo tipo di attacchi è non permettere agli attaccanti di registrare nomi di dominio simili.

Per raggiungere questo obiettivo puoi registrare molti domini bitquattati / typosquatted insieme al tuo nome di dominio principale, ma questo è impossibile da fare con tutti i casi di bitquatting / typosquatting, poiché possono essere miliardi (si consideri anche unicode etc!).

Un'alternativa è monitorare periodicamente i domini registrati, e se trovi un dominio sospetto puoi controllare cosa fa e, se sembra essere un sito malevolo, puoi segnalarlo al registrar e chiedere loro di passare il proprietà di detto dominio per te.

Abbiamo un piccolo servizio, chiamato Precog che fa questo, aggregando le informazioni del registrar da diverse fonti ed eseguendo vari tipi di query per rilevare i domini bitsquatting / typosquatting / punycode-squatting: puoi registrare il tuo marchio, inserire alcune parole chiave e ti contatteremo se un dominio sospetto è registrato.

Il nostro strumento prende in considerazione i domini di secondo livello, ovviamente, ma è anche in grado di rilevare la registrazione di molti domini di terzo livello (o più), quindi potremmo essere in grado di rilevare qualcuno che sta per usare app1e.account.com per provare e rubare le tue credenziali di apple.

Devo aggiungere: credo che il più grande caso di utilizzo per attacchi di questo tipo non sia quello di "essere fortunati" a ricevere una richiesta perché qualcuno ha digitato male il dominio, ma di usare il dominio come dominio di phishing. Quindi le persone registreranno il sito àpple.com e invieranno tonnellate di email simili alle e-mail di Apple e cercheranno di invitare alcune persone a inserire le loro credenziali / i dati della carta di credito sulla loro pagina.

Tra tutte le risposte, sono sorpreso di non aver visto un riferimento alla politica di sicurezza dei contenuti .

È fondamentalmente una soluzione one-stop per le fonti di contenuto consentite in white list. Una semplice soluzione sarebbe consentire solo JavaScript dal tuo dominio corrente (www.example.com) e bloccare tutto il resto.

La risposta di Arminius è grandiosa. Puoi anche utilizzare una norma sulla sicurezza dei contenuti come ulteriore linea di difesa contro l'accanimento dei bit.

CSP è un'intestazione HTTP che ti consente di creare una whitelist di URI a grana fine con cui il tuo sito web può comunicare. Ad esempio, puoi dire al browser che consentirai a JavaScript solo di provenire da example.org/js/file1.js, solo le immagini da example.com/imgs e i font da example.net.

Affinché un attacco bit-squat abbia successo, è necessario capovolgere un po 'l'intestazione HTTP AND nella richiesta. Se un utente malintenzionato può capovolgere solo un bit, il tuo sito web genererà molti errori, indipendentemente dal bit che è stato ruotato.