Windows: ¿Algún método para imponer la confirmación del usuario antes de que el navegador abra una URL solicitada por una aplicación de escritorio externa?

3

Un firewall robusto saliente protegerá contra las aplicaciones de escritorio que se conectan directamente a Internet sin su permiso. Sin embargo, como el navegador es una aplicación generalmente autorizada para el acceso a Internet, he empezado a ver más aplicaciones que evitan esto al enviar una solicitud de URL al navegador. Esto es especialmente sospechoso cuando la consulta GET incluye largas cadenas crípticas ...

¿Alguien sabe de alguna solución de Windows o multiplataforma que le pida al usuario una confirmación antes de pasar a la URL o al menos consulte previamente una lista blanca / lista negra?

Para mis propósitos, cualquier bloqueo que solo ocurra después de que el navegador haya intentado acceder a la URL no es adecuado; aunque esto es común por razones algo diferentes en un entorno corporativo.

Aclaración: esta confirmación del usuario de la URL saliente debe ser solo para las URL solicitadas desde fuera del navegador. es decir, algunos OEM bloatware o una aplicación de blackbox freeware deciden abrir una ventana del navegador sin permiso para xyz.com/cgi?mysterious_string en la instalación, desinstalación o alguna otra decisión hermética de la aplicación.

    
pregunta LateralFractal 08.09.2013 - 04:26
fuente

5 respuestas

1

En realidad, existe una solución simple para esto: cree una aplicación que tome un solo parámetro de línea de comando (la URL) y abra el navegador directamente con esa URL después de que se muestre un cuadro de confirmación. Establece esta aplicación como el navegador predeterminado.

Cuando el sistema ve un ShellExecute o CreateProcess con un http:// URI como objetivo, pasa la ejecución al navegador predeterminado según lo establecido en el registro. Su programa puede interceptarlo antes de entregarlo al navegador real.

Pseudocódigo:

int main (int argc, string[] argv)
{
    if (argc != 1)
        return -1;
    string url = argv[1];

    if (MessageBox("Are you sure you want to go to " + url + "?", YesNo) == Yes)
    {
        CreateProcess("path/to/firefox.exe", url);
        return 0;
    }
    else
        return -1;
}
    
respondido por el Polynomial 23.10.2014 - 12:37
fuente
1

Otra solución es crear o modificar un navegador existente, para no permitir ningún tipo de escritura de URL externa. Incluso podría tener que usar un teclado de pantalla o similar para evitar que los programas maliciosos usen SendKeys(); y podría tener codificado el teclado de la pantalla y muchas otras funciones de seguridad, y confirmación del usuario si el navegador se llama externamente con una URL como argumento. Entonces, simplemente aprueba este navegador en su firewall.

    
respondido por el sebastian nielsen 22.10.2014 - 09:36
fuente
0

Hay algunos enfoques diferentes.

Una opción sería implementar un proxy de filtrado de contenido. Puede instalar uno localmente o en el nivel de red. Puede forzar una lista blanca y luego configurarla para que solicite cada URL que no esté en la lista blanca. Sin embargo, me imagino que para la mayoría de las personas que trabajan con una lista blanca es un gran dolor. Sin embargo, muchos proxies de filtrado de contenido mantienen listas negras o tienen heurísticas para analizar una página antes de cargarla.

Muchos navegadores y motores de búsqueda ahora identifican páginas realmente maliciosas antes de que se carguen también.

En Internet Explorer puede configurar Zonas de seguridad y aplicar diferentes niveles de seguridad en función de esto. Por ejemplo, puede agregar sitios a los sitios "Confiables" en los que aplica un menor escrutinio y luego hay sitios "Restringidos" que son más o menos una lista negra. Hay una configuración general para "Internet", puede personalizar el nivel de los sitios de Internet (que por supuesto son exclusivos de los de la lista "De confianza") para hacer cosas como deshabilitar complementos, deshabilitar descargas, etc. No creo podría requerir una solicitud para cada sitio en la zona de Internet, pero creo que los sitios en la Zona restringida pueden bloquearse o forzar al usuario a borrar un mensaje de advertencia. No estoy seguro de si la configuración de la Zona afecta a otros navegadores, ya que existe cierta integración con la configuración de Internet de IE y el sistema operativo.

También hay una gran cantidad de complementos para los distintos navegadores para agregar listas negras, heurísticas y muchas otras características de seguridad. Una que podría ser adecuada para sus necesidades es Web of Trust , que tiene implementaciones para varios navegadores.

    
respondido por el Eric G 08.09.2013 - 08:06
fuente
0

Sugeriría esto: usar un proxy, que inicialmente bloquea todas las solicitudes. Para cada solicitud bloqueada, para autorizarlos, tendría que escribir un captcha u Otro factor desafiante que el programa malintencionado NO podrá pasar.

Si se pasa el captcha, entonces el sitio en cuestión se agregará permanentemente a una lista blanca que le permitirá pasar cada vez. Por supuesto, el sistema ni siquiera debe pasar la solicitud de DNS antes de que se confirme la url.

También puede tener un "registro" donde puede escribir como enlace y ver todos los sitios que se han bloqueado y permitido. Y desbloquee sitios de terceros importantes que, por ejemplo, carguen contenido de script. (y posible eliminar sitios de la lista blanca)

¡Usar un software local para bloquear llamadas externas al navegador web no es seguro! Un programa malintencionado siempre puede omitir esto: piense en el control de clics, el control remoto (estilo VNC), etc. Incluso podría hacer un SendKeys('http://www.maliciousurl.com{ENTER}'); tan pronto como haga clic en la barra de dirección en su barra de dirección para escribir su propia URL. Y tan pronto como se carga la url, es demasiado tarde.

Una solución captcha evitará el acceso a cualquier URL maliciosa, lo que a su vez evitará que cualquier software se conecte al atacante para el control remoto. Así que este sería un momento 22 para el atacante: Para el control remoto, necesitaría la aprobación de su servidor, pero para que su servidor sea aprobado, necesita el control remoto. Por lo tanto, la única forma de evitar el sistema sería construir un decodificador de captcha, pero si el captcha es bueno, debería ser bastante imposible.

Lo bueno de esto es que hará que su sistema "aprenda", por ejemplo, cada vez que autorice un sitio, se guardará, por lo que el sistema aprenderá automáticamente qué sitios visita regularmente, por lo que obtendrá captchas cada Minuto la primera hora, básicamente, utiliza el sistema, pero gradualmente casi nunca tendrá que escribir un catpcha.

    
respondido por el sebastian nielsen 22.10.2014 - 09:25
fuente
0

No he visto ningún giro entre el navegador y el usuario que pueda informarles antes de que se realice la conexión. Cualquier complemento o aplicación llevaría a un serio proceso de procesamiento de tantas variables. Vamos a echar un vistazo:

Requester (via browser whether initiated or not) --> browser --> Go get this malice.com/bad.cgi

¿Hasta qué punto cree que podría procesar las iteraciones cuando bad.cgi cambia cada N cantidad de minutos, segundos, etc.? Olvídese de las iteraciones, ¿qué piensa hacer cuando la solicitud se convierta en:

Requester --> browser --> www.urlshortenerservice.com/tempURI

La conexión ya fue iniciada. Por lo que sabe, la malicia podría ocurrir en el servicio de acortamiento de URL antes de pasar a una página legítima.

Mi opinión, cuando se trata de malware / sitios / redes maliciosos, está en la lista negra en el lado de OUTBOUND de la ecuación. Noté la mención de "zonas de seguridad" que no siempre funcionan. Ha habido casos en los que los autores de malware compran espacios publicitarios legítimos para infectar a los visitantes. Imagine lo siguiente: Los ataques maliciosos compran palabras / gráficos de anuncios en, por ejemplo, Yahoo.com. Es un sitio incluido en la lista blanca, el navegador en su sabiduría de "zonas de seguridad" permitiría la conexión. No hay un método definitivo para evitar que esto suceda, sin importar qué tan profunda sea su "inspección profunda de paquetes".

En la otra cara de la ecuación, recuerde que nosotros (usted) estamos tratando de evitar que su máquina realice una mala elección (conexión). Los operadores de sitios web maliciosos / maliciosos a menudo programan diferentes mecanismos para "salir", por ejemplo:

maliciousSomething --> try getting here --> Interwebs ; if fail then ;
try getting here instead --> Interwebst ; if fail then ;
generate obfuscation --> try getting here

¿Qué es lo común aquí? ... El destino "aquí" donde "aquí" se puede aislar no solo en el corp. firewall, pero también en firewalls locales (local como en los firewalls de Windows). La desventaja de esto es que los autores maliciosos ponen en peligro las máquinas todo el tiempo, por lo que las listas negras, listas blancas son una batalla perdida.

Si las cosas son "ese extremo" donde la seguridad es la prioridad "máxima", entonces recomiendo usar un proxy (Calamar o algo así) junto con redes , y eliminando cadenas potencialmente peligrosas antes de que se realice la conexión. por ejemplo

machineOnNetwork --> gohere.com/malicious.js --> proxy --> interwebs
proxy --> before I send you anywhere... Let me regex check and replace things --> interwebs

Eso también se vuelve engorroso, ya que potencialmente tendrías una cantidad infinita de reglas de expresiones regulares al final del día. Lo que publicaste es una batalla continua que la mayoría de los proveedores de AV realizan a diario, así como los desarrolladores de software. Me encantaría ver tu solución al final del día. Si me preguntas, solo hay bandasidas para este problema.

    
respondido por el munkeyoto 22.10.2014 - 15:51
fuente

Lea otras preguntas en las etiquetas