¿Cómo puedo proteger mi sitio web contra los bitsquatting?

  

¿Existe alguna técnica de defensa estándar contra ella?

Como se describe en las otras respuestas, los errores de bits al consultar nombres de dominio pueden no ser una amenaza realista para su aplicación web. Pero suponiendo que lo sean, entonces Integridad del sub-recurso (SRI) ayuda

Con SRI, está especificando un hash del recurso que está cargando en un atributo integrity , de este modo:

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

De ahora en adelante, no importa si el script se obtiene de un dominio diferente debido a un error de bit (o modificado por un MITM) porque su navegador se negará a ejecutar el script si el hash de su contenido no lo hace t coincide con el valor de integridad. Entonces, cuando un poco de error, o cualquier otra cosa, hizo que la URL se resolviera para el dxample.org controlado por el atacante, el único script que podrían inyectar con éxito sería uno que coincida con el hash (es decir, el script que pretendía cargar de todos modos).

El caso de uso principal de SRI es recuperar secuencias de comandos y hojas de estilo de CDN no confiables, pero funciona en cualquier escenario en el que desee asegurarse de que el recurso solicitado no esté modificado.

Tenga en cuenta que el SRI está limitado a script y link por ahora, pero el soporte para otras etiquetas puede aparecer más adelante:

  

Nota: es probable que una futura revisión de esta especificación incluya soporte de integridad para todos los subresources posibles, es decir, a , audio , embed , iframe , img , link , object , script , source , track y video elementos.

(De la especificación)

(Consulte también este ticket de error)

Es muy probable que su preocupación sea infundada.

En primer lugar, debe darse cuenta de lo poco probable que son estos fallos de memoria. La persona que escribió el artículo anterior registró solicitudes a 32 clones de algunos de los dominios más visitados en Internet en el transcurso de 7 meses. Esos 52,317 hits debían estar entre cientos de miles de millones de solicitudes. A menos que usted maneje un sitio web en la escala de Facebook, un atacante tendría que ser extremadamente afortunado para incluso obtener solo una víctima desafortunada en su dominio de bitsquatting.

Luego hay que tener en cuenta que los errores de memoria causan varios fallos de funcionamiento. El autor escribe:

  

Estas solicitudes [...] muestran signos de varios errores de bit.

Si el sistema de la víctima está tan dañado que ni siquiera pueden enviar una solicitud HTTP sin varios errores de bit, es probable que cualquier malware que descarguen no se ejecute sin errores. Es un milagro que incluso haya podido arrancar en esa condición.

Y con respecto a los casos en los que se encontraron errores de bit en "cachés de aplicaciones web, resolutores de DNS y un servidor proxy" y, por lo tanto, afectan a varios usuarios (algunos de ellos pueden ser lo suficientemente desafortunados como para obtener suficiente malware en un estado ejecutable): En estas situaciones, la respuesta HTTP provendría de un servidor diferente al que el cliente solicitó. Por lo tanto, cuando use solo HTTPS (lo que supongo que usted hace, o tendría ataques mucho más graves de los que preocuparse), entonces su firma no se desprotegerá y el navegador no descargará ese recurso.

Y además, HTTPS también hará que sea mucho menos probable que obtenga una conexión exitosa cuando hay un sistema con RAM roto en la ruta. Un solo cambio de bit en un mensaje cifrado TLS evitará que el hash se retire, por lo que el receptor lo rechazará.

tl; dr: deja de preocuparte y configura solo HTTPS.

Dudo acerca de la fiabilidad del artículo. Mientras que se discutió en DEFCON y se publicó como un documento técnico, tengo serias preocupaciones sobre los resultados experimentales.

Según el comentario de @mootmoot, el autor no pudo determinar los errores de programación determinísticos de las fluctuaciones aleatorias de bits.

Mi declaración concerniente es

  

Durante el período de registro [septiembre 2010 / mayo 2011, ndr] hubo un total de 52,317 solicitudes de bitsquat desde 12,949 direcciones IP únicas

No, el autor solo demostró que se contactó con sus dominios de sentadilla, pero probablemente no proporcionó información adicional

1. ¿Qué porcentaje de la red CDN original representa ese tráfico (esto es verificable en teoría, pero no tengo esas cifras)?
2. Ocurrencia de dominios de referencia de origen

El segundo es muy importante porque ayuda a aislar fallas de programación deterministas de fluctuaciones aleatorias de bits.

Considere el siguiente ejemplo: si encuentra alguna entrada en gbcdn.net (facebook squat) con el referer https://facebook.com , es probable que haya encontrado un bit quat.

Si, por el contrario, encuentra varias entradas de un sitio web poco conocido que puede inspeccionar para encontrar con un botón con el estilo roto , entonces el problema probablemente se deba a que un programador no está copiando / pegando el código. correctamente, o incluso un poco flip ocurrió en el IDE del programador. Quien sabe ...

Descargo de responsabilidad : soy empleado de Emaze Networks S.p.A.

Una forma de defenderse contra este tipo de ataques es no permitir que los atacantes registren nombres de dominio similares.

Para lograr esto, puede registrar muchos dominios de bitquatted / typosquatted junto con su nombre de dominio principal, pero esto es imposible de hacer con todos los casos de bitquatting / typosquatting, ya que pueden ser miles de millones (considere también Unicode, etc.).

Una alternativa es monitorear periódicamente los dominios registrados, y si encuentra un dominio sospechoso, puede verificar qué hace y, si parece ser un sitio malicioso, puede reportarlo al registrador y pedirle que pase el propiedad de dicho dominio para ti.

Tenemos un pequeño servicio, llamado Precog que hace esto, agregando información de registrador de diferentes fuentes y ejecutando diversos tipos de consultas para detectar dominios de bitsquatting / typosquatting / punycode-squatting: puede registrar su marca, poner algunas palabras clave y nos pondremos en contacto con usted si se registra un dominio sospechoso.

Nuestra herramienta toma en consideración los dominios de nivel 2, obviamente, pero también puede detectar el registro de muchos dominios de nivel 3 (o más), por lo que podemos detectar que alguien va a usar app1e.account.com para intentar robar tus credenciales de Apple.

Debo agregar: Creo que el caso de uso más grande para este tipo de ataques no es "tener suerte" para recibir una solicitud porque alguien escribió el dominio de forma errónea, sino usar el dominio como dominio de phishing. Así que la gente registrará el sitio àpple.com y enviará toneladas de correos electrónicos que parecen los correos electrónicos de Apple e intentará que algunas personas inserten sus credenciales / información de tarjeta de crédito en su página.

Entre todas las respuestas, me sorprende que no haya visto una referencia a Política de seguridad de contenido .

Básicamente es una solución única para las fuentes de contenido permitidas en la lista blanca. Una solución simple sería permitir solo JavaScript desde su dominio actual (www.example.com) y bloquear todo lo demás.

La respuesta de Arminio es genial. También puede usar una fuerte Política de seguridad de contenido como otra línea de defensa contra la ocupación de bits.

CSP es un encabezado HTTP que le permite crear una lista blanca de URIs con las que su sitio web puede comunicarse. Por ejemplo, puede decirle al navegador que solo permitirá que JavaScript venga de example.org/js/file1.js, solo permita imágenes de example.com/imgs, y fuentes de example.net.

Para que un ataque de posicionamiento de bits sea exitoso, necesitarían voltear un poco en el encabezado HTTP Y en la solicitud. Si un atacante puede voltear solo un bit, entonces su sitio web generará muchos errores, independientemente de qué bit se haya volteado.