Shashi Kant Sharma dio un excelente recorrido sobre cómo funciona esto, pero me gustaría agregar algunas estrategias de mitigación:
* Los procedimientos almacenados son su amigo, especialmente para el inicio de sesión / autenticación SQL. Me doy cuenta de que algunas personas se oponen filosóficamente a los desencadenantes y los procedimientos almacenados, pero sugiero respetuosamente que esas personas lo superen.
En el ejemplo de Shashi, la razón por la que ‘SELECCIONAR correo electrónico, contraseña de …’ funciona es porque eso es todo lo que hace. Está buscando ‘n’ filas, donde n> 0. Pero esa no es la forma en que debería funcionar la autenticación. Debe haber una y SOLO una fila devuelta. Este simple control eliminaría el 90% de este estilo más popular de ataque de inyección sql. Por ejemplo…
- ¿Cómo se crean las botnets de malware a gran escala?
- ¿Qué es el enraizamiento?
- ¿Hay alguna manera de piratear el teléfono móvil de alguien cuando la otra persona está en un lugar diferente?
- ¿Por qué debería usar Arch Linux para hackear?
- ¿Qué es el túnel HTTP y cuáles son sus usos prácticos?
1. el procedimiento almacenado ejecuta ‘SELECCIONAR correo electrónico, contraseña de …’
2. comprobaciones de procedimiento almacenado para rowcount = 0; lo que debería informar a la aplicación que llama para decirle al usuario que “intente nuevamente”
3. comprobaciones de procedimiento almacenado para recuento de filas> 1; suponiendo que la columna de correo electrónico es única / no nula, ahora sabe con un 99% de certeza que este es un intento de inyección sql; alertar a la aplicación que realiza la llamada y REGISTRARLO, posiblemente prohibiendo la IP del cliente en intentos posteriores
4. el usuario solo se autentica si rowcount = 1
5. Otra cosa interesante de los procedimientos almacenados es su capacidad de tener tipos de datos y TAMAÑOS preestablecidos en los valores de entrada, para evitar que los intentos de pirateo inunden su código con bytes sin sentido que podrían explotar alguna vulnerabilidad indocumentada.
* Del mismo modo, manténgase alejado de las pruebas ‘SI EXISTE’ … ¡siempre verifique el número de filas devueltas de una consulta de autenticación! El hack de estilo ‘OR 1 = 1’ que Shashi describió devolverá varias filas; Esa es tu pistola humeante.
* NUNCA use sql dinámico, como en …
SET @my_sql_code = 'SELECCIONAR correo electrónico, contraseña de' + + 'DONDE algo bla, bla, bla ...' EJECUTAR @my_sql_code
… porque el hacker tiene la capacidad de hacer cualquier valor nefasto que quiera. Pase siempre los valores a un procedimiento almacenado o API / servicio web intermedio y deje que maneje la transferencia directa de la base de datos subyacente después de asegurarse de que los datos de entrada estén limpios.
* Desactive los informes de errores de db / app: así es como los hackers de inyección sql hacen gran parte de su trabajo sucio. “Agitan el control” con muchas técnicas diferentes diseñadas para enviarles deliberadamente mensajes de error innecesariamente detallados en un intento de mapear sus tablas de usuario y sistema, luego por proceso de eliminación y conjeturas = voila = están en.
Cada lenguaje web / framework / etc moderno tiene los medios para agrupar códigos de error, un volcado de pila + informe completo del entorno y registrarlo, enviárselo por correo electrónico, lo que desee. Lo mejor es devolverle al usuario algo inocuo y vago, como “error 666: nombre de usuario / pwd no válido” o algún mensaje diferente al mensaje estándar “inténtelo de nuevo”. De esa manera, si es un usuario legítimo y lo llaman / envían un correo electrónico con un “error 666 wtf?” sabrá que puede ser que su nombre de usuario y / o pwd tengan algunos apóstrofes (‘) desafortunadamente colocados en ellos.
* NUNCA use las cuentas de usuario sa, sysadmin o root de su base de datos para ejecutar consultas en nombre de su servidor web. Siempre cree una cuenta de tipo www_db_dummy con pocos privilegios que SOLO tenga acceso a la cantidad de columnas, tablas, vistas, procesos almacenados y disparadores necesarios. Al final es más trabajo porque usará muchas declaraciones GRANT, pero esta estrategia hará que sus órdenes de magnitud db sean más seguras contra los ataques de inyección sql y le brindará una enorme tranquilidad al mismo tiempo.
Si todos siguieran los pasos anteriores todo el tiempo, probablemente habría una reducción del 99% en los ataques de inyección SQL durante la noche.
¿Quiere hacer un truco divertido que le dirá si un sitio web es vulnerable a la inyección de SQL, probablemente porque tontamente usan SQL dinámico? Simplemente ingrese un signo de porcentaje ‘%’ (sin las comillas) en uno de los campos de formulario del sitio web y vea lo que hace. Por ejemplo, hace un tiempo estaba usando un sitio frustrante que lo obligaba a conocer parte del apellido de un médico o grupo de práctica / médico antes de devolver una lista del área. Como estaba buscando un nuevo médico, no sabía un nombre, pero solo quería ver a todos los que figuran en el código postal. Frustrante. Mala experiencia de usuario. Entonces, pensé que alguien con malas habilidades de diseño de sitios web también podría tener poco conocimiento de SQL, así que ingresé% en el apellido y los campos de grupo y * boom * obtuve un volcado completo de los miles de documentos en su base de datos, tal como quería .
No me considero un hacker, pero si pudiera hacer eso, ¿qué crees que una persona verdaderamente malvada podría inyectar en tu aplicación web?
