Si alguien configuró con éxito un sitio web de suplantación de identidad (phishing) en una red inalámbrica falsa, por ejemplo, bankofamerica.com, y simulamos que no se usó SSL, ¿podrían ejecutar un script en el servidor que lea el contenido de las cookies de alguien? ¿Quién se conectó a él (por ejemplo, un token de autenticación a largo plazo)?
Suponiendo un pharming en lugar de phishing ... Aquí es donde el nombre de dominio se redirige a un sitio falso en lugar de que Typosquatting o engañar al usuario para que visite un sitio totalmente diferente que se parece al objetivo.
La diferencia aquí es crucial: el dominio efectivo del sitio falso visto por la víctima que es en realidad el mismo que el sitio real hará que el navegador trate el sitio falso como el mismo Origen .
Esto significa que las cookies, el almacenamiento local, etc., estarán disponibles en el sitio falso.
Dos puntos de mitigación:
Si no se aplica ninguna de las condiciones anteriores y el usuario tuvo una sesión autenticada contra el sitio falso, las cookies se enviarán al sitio falso, incluidas las utilizadas para la autenticación. Con suerte un banco habrá tomado cualquiera de las precauciones anteriores, pero no siempre es el caso.
Sí, el atacante puede enviarle un enlace malicioso y, si hace clic en él, la información de la cookie pasará al atacante. Tales tipos de ataques se denominan ataques de secuencias de comandos de sitios cruzados XSS . El escenario de ataque puede ser de dos tipos: 1. XSS almacenado . 2. XSS reflejado
Sí, suponiendo que no se usa HTTPS.
En su situación, ejecuta la puerta de enlace inalámbrica y tiene la capacidad de hacer que bankofamerica.com se resuelva en un host diferente al que tendría en la Internet pública. Este es un ataque de pharming .
Las cookies están vinculadas a un nombre de dominio . Cuando un servidor envía un encabezado de respuesta Set-Cookie , o una secuencia de comandos usa document.cookie para establecer una cookie, decimos que la cookie está establecida por (o para ) < em> ese dominio . En general, la capacidad de leer cookies para un nombre de dominio particular está limitada al servidor con ese nombre de dominio. Esto tiene implicaciones de ataque obvias si el nombre bankofamerica.com de repente se refiere a una dirección IP diferente.
Cada vez que su navegador envía una solicitud a un servidor llamado bankofamerica.com , incluye las cookies establecidas por bankofamerica.com en la solicitud. Si el servidor real (o la dirección IP) que se alcanza cuando su computadora solicita bankofamerica.com cambia, a su navegador no le importa, y le enviará las cookies de bankofamerica.com -set al servidor de nombre aceptable (pero en realidad malicioso) . (Considere: a veces la dirección IP asociada con un nombre de dominio puede cambiar legítimamente; ¿cómo sabría su sistema si un cambio es legítimo o un ataque?)
Como usted controla este servidor malicioso, puede ver todo el tráfico que entra y sale. Por lo tanto, puede ver los encabezados de las cookies que envía el navegador del cliente al servidor. Sin embargo, si controla el enrutador, puede ver toda esa información incluso antes de que llegue a su servidor malicioso (a través del propio enrutador), por lo que no hay una buena razón para configurar un servidor malicioso además de su enrutador malicioso Sin embargo, si de alguna manera logró cambiar el registro de DNS bankofamerica.com del cliente sin controlar completamente el enrutador, entonces su idea de servidor falso se ajusta perfectamente a sus requisitos.
Tenga en cuenta que HTTPS hace un buen trabajo al bloquear este ataque. Su servidor no puede suplantar con éxito una conexión segura a bankofamerica.com , porque no tiene un certificado firmado por una autoridad de certificación en la que el usuario confía. Ninguna autoridad de certificación le otorgaría un certificado firmado para bankofamerica.com a menos que pudiera demostrar que realmente posee la propiedad real (lo que obviamente no puede probar, porque no la posee). Cuando intentes redirigir la conexión segura del cliente a tu servidor falso, el cliente recibirá una alerta de que se está produciendo un posible ataque.
Si el usuario probara por primera vez http://bankofamerica.com en lugar de ir directamente a https://bankofamerica.com , su malvado servidor podría decir "No es necesario actualizar a HTTPS; digamos solo en HTTP simple", y el cliente no recibirá una advertencia sobre certificados Este es un ataque de eliminación de SSL . Esto se puede evitar mediante HSTS , que un servidor puede usar para decirle a un cliente: "Nunca se comunique con este host por una conexión insegura. para los próximos XX días / meses / años ".
Otra medida de protección posible con HTTPS es la bandera de cookie segura . El navegador no enviará cookies de marca segura al dominio propietario a menos que la solicitud se realice a través de HTTPS. Como su servidor no puede hacerse pasar por el dominio de destino a través de una conexión segura, nunca podrá ver cookies seguras.
Sí, pueden, pero dependiendo del navegador, ni siquiera tiene que ser un ataque de phishing. Internet Explorer 11 tiene una vulnerabilidad reciente Eso le permite a un atacante robar cookies.
Muchos lenguajes de programación diferentes pueden ejecutarse en sitios web y hay comandos que pueden hacer algunas cosas que dan miedo. Si está en Linux, puede configurar un nuevo perfil aislado solo para Firefox para que su sistema esté protegido. Sí, incluso Linux puede ser impulsado por Java y atacar el cargador de arranque con un ataque remoto de Maid. (¿Por qué mencioné a la criada malvada? Porque solo estoy dando un ejemplo de hasta dónde puede llegar una vulnerabilidad de navegador).