Domanda:
Come posso proteggere il mio sito web dal bitsquatting?
Benoit Esnard
2018-05-08 16:54:52 UTC
view on stackexchange narkive permalink

Ho appena letto un articolo sul bitsquatting (che si riferisce alla registrazione di un nome di dominio leggermente diverso da un dominio popolare) e sono preoccupato di come potrebbe consentire a un utente malintenzionato di caricare le proprie risorse sul mio sito web.

Ad esempio, se il mio sito web si trova in https://www.example.org/ carica un file di script situato in https : //www.example.org/script.js , un utente malintenzionato potrebbe registrare dxample.org e ospitare un file JS dannoso, che verrebbe scaricato ed eseguito da alcuni utenti del mio sito web.

Esiste una tecnica di difesa standard contro di essa?

Il typosquatting sembra essere molto più grande.E io per primo non credo che il traffico di doublechick.net sia stato solo un errore!
Non credo che tu possa farci niente.Inoltre, è difficile trarre una conclusione dall'articolo che hai mostrato, poiché è impossibile sapere se quei traffici sono davvero bitsquat o solo un errore di programmazione dalla chiamata a una pagina web.
È una domanda teorica o sei sinceramente preoccupato per il tuo sito?Gestisci un dominio popolare, con milioni di visitatori?
@Bergi: questa è una domanda teorica.Ho già lavorato su siti web con milioni di visitatori, ma c'erano problemi maggiori rispetto al bitsquatting poiché, come affermato da alcune risposte, è un evento molto raro.:)
Se ti interessa la sicurezza, perché stai utilizzando http anziché https in primo luogo?
@Acccumulation: questa è stata una svista nella mia domanda, poiché non sono riuscito a raggiungere example.org tramite HTTPS quando ho creato la domanda.Il problema è ora risolto: la domanda presume che HTTPS sia già in uso per ogni risorsa del sito.Grazie per averlo indicato!
Se stai usando HTTPS, l'attaccante dovrebbe ottenere un certificato per `esempio.com`, o ottenere un certificato per` dxample.com` e fare in modo che il client non noti che il certificato non è per `esempio.com`.Non so abbastanza su HTTPS per sapere se questa è una modalità di attacco praticabile.
@Acccumulation: L'aggressore può facilmente ottenere un certificato per `dxample.com` poiché possiede il dominio.L'utente non può controllare facilmente il certificato, a meno che non stia monitorando attivamente l'attività di rete.Ad esempio, secondo il blocco degli annunci, questa pagina caricava risorse da 8 domini diversi.Posso facilmente controllare quello associato a `security.stackexchange.com`, ma non riesco a vedere quali certificati sono stati utilizzati per le altre risorse.
Perché non registrare semplicemente tutti i domini che sono fuori di uno?
Questo è ciò che fa GitHub: http://guthib.com
@nalzok: Ebbene, guardando i record WHOIS, questo non è uno dei domini GitHub, ed è più un dominio typosquatted che bitsquatted.
@Therac Il typosquatting è un problema che aumenta le probabilità di successo del phishing ed è essenzialmente un attacco attivo.Il bitsquatting sembra essere una tecnica per trarre vantaggio dai normali errori quotidiani nei risolutori DNS ed è sicuramente un attacco passivo.Anche un utente molto attento può cadere vittima di un dominio "bitsquatted" perché non è possibile effettuare controlli incrociati e intervenire.
Se sei preoccupato per i bitsquatter che ti impersonano / MITM: alza il livello con un certificato EV e dì ai tuoi utenti in bella vista che non dovrebbero fidarsi di nessun sito che non ne ha uno.
@rackandboneman: non puoi vedere facilmente i certificati associati alle sottorisorse, quindi l'utilizzo di un certificato EV non aiuta.
La risposta breve che ti darei è che se sei davvero preoccupato per qualcosa di così difficile da sfruttare, e questo accade incredibilmente raramente come "bit-squatting", o hai troppo tempo a disposizione, o non farlot capire le reali minacce per il tuo sito web.(Noterai che l'autore di questo "attacco" non ha fornito numeri reali di quanto spesso questo dovrebbe accadere, ma solo un po 'di gesti su numeri grandi e piccoli).In altre parole, concentra i tuoi sforzi altrove.
Quante volte accade anche questo?Considerando i miliardi di operazioni al minuto che un PC moderno e complesso fa, non potrebbe fare quello che fa se gli errori di bit fossero * anche rari *.Si sarebbero schiantati ogni giorno.E non lo fanno.
Sei risposte:
#1
+131
Arminius
2018-05-08 17:32:24 UTC
view on stackexchange narkive permalink

Esiste una tecnica di difesa standard contro di essa?

Come sottolineato nelle altre risposte, gli errori di bit quando si interrogano i nomi di dominio potrebbero non essere una minaccia realistica per la tua applicazione web. Ma supponendo che lo siano, allora Integrità sottorisorse (SRI) aiuta.

Con 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> > ora lo fa  Non importa se lo script viene recuperato 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 corrisponde al valore di integrità. Quindi, quando un piccolo errore, o qualsiasi altra cosa, ha fatto sì che l'URL venisse risolto nel  dxample.org  controllato dall'attaccante, l'unico script che potevano iniettare con successo sarebbe stato quello corrispondente all'hash (cioè, lo script che intendevi 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 desideri assicurarti che la risorsa richiesta non sia modificata.

Nota che SRI è limitato a script e link per ora, ma il supporto per altri tag potrebbe arrivare in seguito:

Nota: è probabile che una futura revisione di questa specifica includa il supporto dell'integrità per tutte le possibili sottorisorse, ad esempio a , audio , embed , iframe , img , link , object , script , source , track e video .

(dalla specifica)

(Vedi anche questo bug ticket)

[Secondo MDN] (https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity), SRI funziona solo per le sottorisorse "