Problemas para entender las vulnerabilidades de inicio de sesión

Ambos casos son vulnerabilidades graves y el enfoque de seguridad es incorrecto.

En primer lugar, la forma en sí no debería escapar de nada. Es posible que desee comprobar la entrada, pero no la manipule. El escape se realiza en un contexto específico como una consulta de base de datos, no globalmente.

No, no es seguro anteponer simplemente una barra invertida a comillas simples en la aplicación:

• Los sistemas de bases de datos admiten diferentes codificaciones de caracteres que pueden coincidir o no con la codificación utilizada por su aplicación. Si no coinciden, el intento de escape es esencialmente un tiro en la oscuridad y puede que no funcione en absoluto. Hay un famoso ataque con inyección que explota las diferencias entre dos codificaciones de caracteres comunes . La única forma de estar seguro es usar una función de biblioteca que tenga en cuenta la codificación de su sistema de base de datos. Por ejemplo, MySQL tiene mysql_real_escape_string() .
• Backslash-escaping es un mecanismo no estándar que solo funciona en algunos modos especiales de algunos sistemas de bases de datos (como MySQL). Si la configuración del servidor o la base de datos subyacente cambian, puede perder nuevamente toda la protección.
• Hay muchos más personajes que debes cuidar. Esto también depende del sistema de base de datos y su configuración.

El escape manual de SQL es en realidad un enfoque bastante pobre, porque es complicado, tedioso y propenso a errores (como puede ver). Una solución más moderna es utilizar declaraciones preparadas y no rellenar ningún dato del usuario en las consultas SQL en primer lugar. Si, por alguna razón, las declaraciones preparadas no son una opción, asegúrese de usar la función de biblioteca correcta en lugar de intentar inventar su propia solución.

Su segundo caso es una vulnerabilidad de secuencia de comandos en todo el sitio, por lo que un atacante puede hacer cualquier cosa que sea posible con XSS (como robar una cookie de sesión). No, XSS no se limita a las URL de ninguna manera. Acabas de probarlo tú mismo. Un ataque XSS ocurre cuando un usuario puede inyectar datos en un contexto HTML. De donde provienen esos datos es irrelevante; podría ser la URL, podría ser un parámetro de formulario, podría ser una cookie, un encabezado HTTP, una cadena de base de datos, cualquier cosa.

OWASP ofrece algunos consejos sólidos en su sitio: enlace Estará más seguro y mejor usando un pozo -recurso esperado que inventar su propia solución a través de prueba y error.

Sin embargo, aprender cómo funciona un atacante a través de la experimentación como lo está haciendo usted, es una de las mejores maneras de aprender cómo funciona todo y por qué es tan importante. Esto te hará un mejor desarrollador.

si aún está confundido por el segundo ejemplo y quiere pensar en un ataque sin URL, imagine que se le pide a un usuario del sitio web una autenticación secundaria pero ya está autenticado (como en un sitio web de un banco cuando a menudo se le pide que ingrese su contraseña nuevamente para autorizar una transferencia). La persona solicita que se complete una acción (como el ejemplo de transferencia bancaria) y no se da cuenta de que la acción aún no se ha completado, pero se llevan a la página de autenticación con su formulario de inicio de sesión para la autenticación secundaria. Se alejan de su escritorio porque piensan erróneamente que ahora todo está completo (¡mucha gente nunca se desconecta, lo que es un problema!) Un atacante que pasa se acerca a su pantalla y ingresa un script en el cuadro de inicio de sesión que regresa la cookie de la sesión, escribe la sesión (o simplemente usa el cliente de correo electrónico para enviarla por correo electrónico a sí mismos) y desaparece en una computadora cercana y usa esa cookie para comenzar a usar el sitio web por sí mismos.

¡Una desagradable! Estoy seguro de que se puede pensar en uno de los cien ejemplos sin las URLs involucradas (piense en alguien que le pide a un usuario que escriba algo en su cuadro de inicio de sesión "como una prueba de seguridad, señor. Me gustaría que escribiera bla bla ".. y así continúa!

Además, recuerde que muchos sistemas auditarán las entradas de nombre de usuario y contraseña (¡esto último en forma cifrada, espero!) en los archivos de registro y las bases de datos, por lo que, con esta vulnerabilidad, un usuario arbitrario puede insertar un código de script en su base de datos o archivo de registro y Los usuarios técnicos con clientes que no están necesariamente libres de inyección o fallas XSS podrían leer esos datos y desencadenar un ataque en su sistema.