Captura de la contraseña escrita en la página web - Reemplazo de HTML [cerrado]

  

Cuando un usuario realiza una solicitud a un servidor, el navegador no tiene idea de que se va a cifrar (la conexión no se ha publicado todavía, al menos en los primeros milisegundos).

El usuario no hace una solicitud al servidor, el navegador lo hace. El usuario a lo sumo solicita al navegador que se conecte a un sitio específico haciendo clic en un enlace o ingresando explícitamente una URL en la barra de estado. Solo en el segundo caso puede ser que no haya una especificación de protocolo explícita dada por el usuario (es decir, www.example.com en lugar de https://www.example.com ), por lo que el navegador debe adivinar si el usuario quiere decir http://.. o https://.. . En este caso, asumirá http://.. inseguro a menos que ya sepa mejor que https://.. debería usarse en su lugar. El navegador puede tener este conocimiento de una conexión anterior donde había un redireccionamiento permanente a HTTPS o un encabezado HSTS dentro de una respuesta anterior de el sitio de destino que especificó que en el futuro solo se debe usar HTTPS. O el navegador puede venir con información HSTS precargada, en cuyo caso no se necesita una visita previa al sitio específico. Por ejemplo, Firefox y Chrome vienen con HSTS precargados para algunos sitios esenciales como google.com.

Por lo tanto, en todos los casos se sabe por la URL antes de conectarse si se debe usar HTTP o HTTPS. El único problema es si el usuario ingresó una URL parcial (sin especificación de protocolo) que el navegador aún no conoce el sitio de destino y, por lo tanto, podría haber adivinado la intención del usuario al elegir HTTP en lugar de HTTPS. Por lo tanto, el navegador puede tener la idea equivocada de qué protocolo utilizar, pero es incorrecto decir que el navegador no tiene idea en absoluto de qué protocolo utilizar. Y si se usa HTTPS, un atacante en la red local no podría simplemente responder con algunos datos falsos como imagina, a menos que el atacante tenga un certificado válido para el sitio de destino emitido por una CA de confianza. Así es como funciona TLS.

  

si mi computadora podría responder rápidamente a la solicitud, tal vez con la   encabezado a la derecha que indica que la solicitud es genuina, entonces el navegador   mostraría mi página web

¿Cómo te imaginas esto trabajando? El navegador realiza una solicitud al servidor en un puerto de origen particular a una IP particular. Si envía un paquete al cliente en ese puerto de origen, el navegador no lo aceptará porque no proviene de la IP correcta. Va a ignorar este nuevo flujo de datos no solicitado.

Además, los firewalls tenderán a bloquear este tipo de tráfico entrante por defecto (no hay conexiones entrantes, solo respuestas en el mismo flujo de IP / puerto / secuencia).

Para que esto funcione, su máquina tiene que ser la persona a la que se realiza la solicitud , y ahí es donde entra MITM. envía una solicitud a Google, designa el Gateway (usted) como el siguiente salto, luego, cuando envíe los datos, el cliente lo interpretará como una conexión válida y mostrará lo que envíe. Pero, la suplantación de ARP tendría que configurarse antes de que se realizara la solicitud (no después) debido a los tiempos del protocolo ARP.

Entonces, no, no es posible la forma en que lo has configurado. Las funciones TCP / IP básicas en la NIC, el sistema operativo y los firewalls evitan que esto suceda.

Eche un vistazo a los firewalls "stateful" vs "stateless" y lo que los hace ver a 'estados', para obtener más información. Cuando Marcus dijo "no es así como funciona la capa de transporte", de esto estaba hablando.