![¿Cuáles son los vectores de ataque para las contraseñas enviadas a través de http?](https://rvso.com/image/515032/%C2%BFCu%C3%A1les%20son%20los%20vectores%20de%20ataque%20para%20las%20contrase%C3%B1as%20enviadas%20a%20trav%C3%A9s%20de%20http%3F.png)
Estoy intentando convencer a un cliente de que pague por SSL para un sitio web que requiere iniciar sesión. Quiero asegurarme de comprender correctamente los principales escenarios en los que alguien puede ver las contraseñas que se envían.
Tengo entendido que en cualquiera de los saltos del camino se puede utilizar unanalizador de paquetespara ver lo que se está enviando. Esto parece requerir que cualquier pirata informático (o su malware/botnet) esté en la misma subred que cualquiera de los saltos que realiza el paquete para llegar a su destino. ¿Está bien?
Suponiendo que parte de este requisito de subred sea cierto, ¿debo preocuparme por todos los saltos o solo por el primero? Obviamente, puedo preocuparme por el primero si están en una red Wifi pública, ya que cualquiera podría estar escuchando. ¿Debería preocuparme por lo que sucede en las subredes por las que viajarán los paquetes fuera de esto? No sé mucho sobre el tráfico de red, pero asumiría que fluye a través de los centros de datos de los principales operadores y que no hay muchos vectores de ataque jugosos allí, pero corríjanme si me equivoco.
¿Hay otros vectores por los que preocuparse además de alguien escuchando con un analizador de paquetes?
Soy un novato en redes y seguridad, así que no dude en aclararme si estoy usando la terminología incorrecta en algo de esto.
Respuesta1
Algo a tener en cuenta que otros no han mencionado aquí es que algunos navegadores almacenan en caché los datos de su formulario. El comportamiento predeterminado en los sitios SSL normalmente es no almacenar nada en caché a menos que elija "guardar mi contraseña". Por lo general, los campos de contraseña no se almacenan en caché de todos modos, pero he visto algunas rarezas (generalmente información de tarjeta de crédito, que sé que no es realmente el tema de la pregunta).
La otra cosa a tener en cuenta es que el cifrado SSL comienza con el protocolo de enlace TCP. Una vez que esté bajo SSL, no podrá distinguir HTTP sobre SSL de FTP sobre SSL (aparte de las suposiciones realizadas a través del número de puerto).
Tampoco puede distinguir una solicitud de inicio de sesión de una solicitud de "Solo estoy navegando", esto confunde el flujo de la página para los posibles piratas informáticos y también garantiza que no solo los datos de su contraseña estén seguros, sino también su historial de navegación/datos de cookies/y cualquier información personal que acompaña a su cuenta.
Total si eliminashombre en el medioataques del espectro usted reduce muchos de los ataques potenciales, pero eso no quiere decir que su sitio sea "seguro". También política de zonificacióndeberíaayuda a protegerlo de ataques XSS ya que realizará un cambio de zona si su usuario es redirigido fuera de su sitio.
Respuesta2
Los datos son vulnerables en cualquier punto de la ruta, no sólo en la primera o última etapa. Es muy posible que un sistema involucrado en la transferencia busque nombres de usuario, contraseñas y otros datos confidenciales. Por lo tanto, los datos confidenciales solo deben viajar a través de un enlace que esté completamente seguro y, por supuesto, para eso es exactamente SSL. Dependiendo de los datos involucrados, es posible que existan leyes locales que dicten SSL.
Respuesta3
Hay servidores proxy que pueden almacenar datos.
Pero también existe la obligación de mantener seguras las contraseñas de los usuarios. Muchos usuarios utilizan un conjunto limitado de contraseñas, por lo que un sitio no seguro podría comprometer la contraseña de su banco, por ejemplo.
Respuesta4
Puedo estar de acuerdo con las reflexiones de KevinM sobre cómo responder sus propias preguntas, y John Gardeniers apunta en la dirección correcta. También debo estar de acuerdo con lo que dijo Silky, "idealmente, el público en general nunca iniciaría sesión en un sitio que no tenga una pantalla de inicio de sesión basada en SSL", y señalo que, sin embargo, este no es el caso actual. en absoluto.
No estoy de acuerdo con el tono de Silky (probablemente sin intención), que conduce a la percepción omnipresente de que "el público en general" es estúpido. El cliente de KevinM claramente no tiene idea de la necesidad de SSL y, en pocas palabras, esa es una persona promedio. No son estúpidos, simplemente no lo saben. Decir "necesitas esto" provocará la respuesta ilícita: "He vivido x años sin él y viviré x más bien", o tal vez incluso una respuesta peor: "Odio que me digan lo que necesito". ". ¡Así que ten cuidado!
Tu preocupación es legítima, Kevin. Su cliente necesita un certificado SSL. Creo que tu verdadera preocupación debería ser cómo venderles uno. No sólo hay que preocuparse por los inicios de sesión de los usuarios, sino también por laadministradoryoperadorinicios de sesión que también se beneficiarían de estar protegidos por SSL.
Sí, hay otras cosas por las que preocuparse a este respecto, incluso más que el rastreo de paquetes, comoXSS. Son numerosos ybien documentada.