Cómo proteger un servidor web DE un servidor proxy inverso

Question

Tengo un sitio web "www.website.com".

Recientemente descubrí que alguien ha configurado un proxy inverso con una URL casi idéntica "www.website1.com" en frente de mi sitio web.

Me preocupan los usuarios que llegaron a mi sitio web a través de ese proxy inverso. Su nombre de usuario y contraseña pueden registrarse cuando inicien sesión.

¿Hay alguna manera de que mi servidor web rechace el proxy inverso?

Por ejemplo, configuré un proxy inverso utilizando squid con la url "www.fakestackoverflow.com" delante de "www.stackoverflow.com". Así que cada vez que escribo "www.fakestackoverflow.com" en la barra de direcciones de mi navegador web, el proxy inverso me redireccionará a "www.stackoverflow.com". Luego noto que la url en mi barra de direcciones cambió a "www.stackoverflow.com", lo que indica que ya no estoy usando el proxy inverso.

"www.stackoverflow.com" debe haber detectado que llegué al sitio web desde otra url y luego me redirigió al sitio web a través de la url real.

¿Cómo hago algo así en la aplicación web ASP.NET?

También asked on server fault.

Answer 1

La manera más simple sería poner un código JavaScript en su página que examina window.location para ver si el dominio de nivel superior (TLD) coincide con lo que espera, y si no, lo reemplaza con su dominio correcto (causando el navegador para recargar al sitio apropiado en su lugar).

Answer 2

En primer lugar, el uso de JavaScript para olfatear document.location.href y compararlo con su dominio:

var MyHostName = "www.mydomain.com"; 
if (0 == document.location.href.indexOf("https://")) 
{ 
    MyHostName = "https://" + MyHostName + "/"; 
    if (0 != document.location.href.indexOf(MyHostName)) { 
     var new_location = document.location.href.replace(/https:\/\/[^\/]+\//, MyHostName); 

     if(new_location != document.location.href) 
      document.location.replace(new_location); 
    } 
} 
else 
{ 
    MyHostName = "http://" + MyHostName + "/"; 
    if (0 != document.location.href.indexOf(MyHostName)) { 
     var new_location = document.location.href.replace(/http:\/\/[^\/]+\//, MyHostName); 

     if(new_location != document.location.href) 
      document.location.replace(new_location); 
    } 
} 

Segunda: escribir un script de inicio para todas las páginas ASP para comprobar si la dirección IP del usuario remoto coincide con la dirección del proxy inverso. Si coincide, redirige a un enlace tinyurl que redirige a tu dominio real. Use tinyurl u otro servicio de redirección para contrarrestar la reescritura url del proxy inverso.

Tercer: escribir una tarea programada para hacer una búsqueda de DNS en el dominio falso, y actualizar un archivo de configuración que su guión de inicio en el paso 2 usos. Nota: No realice una búsqueda de DNS en su ASP porque las búsquedas de DNS pueden detenerse durante 5 segundos. Esto abre una puerta para DOS contra su sitio. Además, no bloquee únicamente según la dirección IP, ya que es fácil reubicarse.

Editar: Si se le considera que el operador proxy roba las contraseñas de usuario y los nombres de usuario, debe registrar a todos los usuarios atendidos en la dirección IP del proxy y deshabilitar sus cuentas. Luego envíeles un correo electrónico explicando que han sido víctimas de un ataque de phishing a través de un nombre de dominio mal escrito, y pídales que cambien sus contraseñas.

Answer 3

Es muy poco lo que puede hacer para evitar esto sin causar errores en los servidores proxy (traducción, caché de google, etc.).Si no le importa si las personas usan dichos servicios, simplemente configure su aplicación web para redirigir siempre si la URL base no es correcta.

Hay algunos pasos que puede seguir si conoce los proxies, y puede averiguar sus direcciones IP, pero eso puede cambiar y usted debe permanecer al tanto. La respuesta de @jmz es bastante buena en ese sentido.

Answer 4

He venido con una idea, y creo que una solución.

En primer lugar, no es necesario sobrescribir todas las páginas porque de esta forma se bloquean otros proxies y otros servicios (como la traducción automática de google).

Digamos que ha ganado para estar absolutamente seguro acerca de la página de inicio de sesión.

Entonces, lo que usted hace, cuando un usuario ingresa en la página login.aspx, realiza una redirección con la ruta completa de su sitio nuevamente para iniciar sesión.aspx.

if(Not all ready redirect on header/or on parametres from url) 
    Responce.Redirect("https://www.mysite.com/login.aspx"); 

De esta manera, no creo que el proxy transparente pueda cambiar el encabezado get y cambiarlo.

También puede registrar cualquier proxy, o grandes solicitudes de algunos ips y verificarlo. Cuando encuentre un Fishing site como el que dice, también puede informarlo.

http://www.antiphishing.org/report_phishing.html
https://submit.symantec.com/antifraud/phish.cgi
http://www.google.com/safebrowsing/report_phish/

Answer 5

Después de días de búsqueda y experimentación, creo que he encontrado una explicación a mi pregunta. En mi pregunta, he utilizado stackoverflow.com como ejemplo, pero ahora voy a utilizar whatismyipaddress.com como mi ejemplo ya que ambos presentan el mismo comportamiento en el sentido de la reescritura de URL más whatismyipaddress.com es capaz para decirle a mi dirección IP.

En primer lugar, con el fin de reproducir el comportamiento, visité whatismyipaddress.com y tiene mi dirección IP, por ejemplo 111.111.111.111 . Luego visité www.whatismyipaddress.com (nótese el www adicional. como su prefijo) y la URL en la barra de direcciones del navegador cambiado de nuevo a whatismyipaddress.com descartando el prefijo. Después de leer los comentarios de Josh Stodola, me empujó a probar este punto.

A continuación, configurar un proxy inverso con la url www.myreverseproxy.com y la dirección IP 222.222.222.222 y tengo que lleva a cabo las siguientes dos escenarios:

1. tengo el los puntos de proxy inverso a whatismyipaddress.com (sin el prefijo ** www.). Luego tipeé www.myreverseproxy.com en la barra de direcciones de mi navegador. El proxy inverso luego me transmitió a whatismyipaddress.com y la url en mi barra de direcciones no cambió (sigue mostrando www.myreverseproxy.com).Confirmé esto al verificar la dirección IP en la página web que mostraba 222.222.222.222 (que es la dirección IP del proxy inverso). Esto significa que todavía estoy viendo la página web a través del proxy inverso y que no estoy conectado directamente al whatismyipaddress.com.

2. entonces tengo los puntos de proxy inverso a www.whatismyipaddress.com (con el prefijo wwww. este momento). Visité www.myreverseproxy.com y esta vez la url en mi barra de direcciones cambió de www.myreverseproxy.com a whatismyipaddress.com. La página web mostró mi dirección IP como 111.111.111.111 (que es la dirección IP real de mi pc). Esto significa que ya no veo la página web a través del proxy inverso y me redirecciona directamente al whatismyipaddress.com.

Creo que este es algún tipo de truco de reescritura de URL que Josh Stodola ha señalado. Creo que voy a leer más sobre esto. En cuanto a cómo proteger un servidor del proxy inverso, la mejor opción es usar SSL. La información encriptada que pasa a través de un proxy no servirá de nada, ya que no se puede leer a plena vista, lo que impide el espionaje y el ataque man-in-the-middle, que es exactamente el proxy inverso.

La protección con javascript puede verse trivial ya que javascript puede ser eliminado fácilmente por un proxy inverso y también evita que otros servicios en línea como google translate accedan a su sitio web.

Answer 6

Si realiza Autenticación sobre SSL utilizando https: //, puede omitir el proxy en la mayoría de los casos.

También puede buscar el encabezado X-Forwarded-For en la solicitud entrante y hacerla coincidir con el proxy sospechoso.

Answer 7

Quizás cree una lista negra de URL y compare las solicitudes con Response.Referer si el sitio web está en esa lista, luego cancele la solicitud o realice una redirección propia.

La lista negra es obviamente algo que tendrías que actualizar manualmente.

Answer 8

Como lo veo, su problema fundamental aquí es que cualquier medida de defensa de capa de aplicación que ponga en marcha para mitigar este ataque puede ser solucionada por el atacante, asumiendo que se trata de un ataque malicioso realizado por un adversario competente.

En mi opinión, definitivamente debe usar HTTPS, que en principio le permitiría al usuario confirmar con seguridad si están hablando con el servidor correcto, pero esto depende de que el usuario sepa verificar esto. Algunos navegadores actualmente muestran información adicional en la barra de URL sobre qué entidad legal posee el certificado SSL, lo que ayudaría, ya que es poco probable que un atacante pueda convencer a una autoridad de certificación legítima para que emita un certificado a su nombre.

Algunos de los otros comentarios indicaron que los servidores proxy intermedios pueden interceptar HTTPS, lo que en realidad no es cierto. Con HTTPS, el cliente emite una solicitud CONNECT al servidor proxy, que canaliza todo el tráfico futuro directamente al servidor de origen, sin poder leer nada de eso. Si suponemos que este servidor proxy es completamente personalizado y malicioso, puede finalizar la sesión SSL e interceptar el tráfico, pero solo puede hacerlo con su propio certificado SSL, no con el suyo.Este certificado será autofirmado (en cuyo caso los clientes recibirán muchos mensajes de advertencia) o un certificado genuino emitido por una autoridad certificadora, en cuyo caso tendrá el nombre de la entidad jurídica incorrecta, y usted podrá volver atrás. a la autoridad certificadora, revoque el certificado y, potencialmente, solicite a la policía que actúe contra el propietario del certificado, si tiene sospechas razonables de que está cometiendo un fraude electrónico.

La otra cosa que se me ocurre que mitigar esta amenaza en cierta medida sería implementar la funcionalidad de contraseña de una sola vez, ya sea utilizando un hardware/software de fichas o utilizando (mi favorito personal) un SMS enviado a la el teléfono del usuario cuando inicie sesión. Esto no evitaría que el atacante tenga acceso a la sesión una vez, pero debería evitar que puedan iniciar sesión en el futuro. Puede proteger aún más a los usuarios al requerir otra contraseña única antes de permitirles ver/editar detalles particularmente confidenciales.

Answer 9

Ok, me encontré con una situación similar, pero logré superarla usando otro dominio reenviado que apunta a mi original de forma permanente, luego verificando con código si el cliente es el servidor inverso o no si lo redireccionaba a mi segundo dominio que irá al original Echa un vistazo a más información desde aquí: http://alphablog.xyz/your-website-is-being-mirrored-by-someone-else-without-your-knowledge/