¿Podría el hashing evitar la inyección de SQL?

Por lo tanto, el hashing de la contraseña del usuario antes de ingresarla en la consulta es una característica de seguridad coincidente para evitar la inyección de SQL, pero no necesariamente puede hacerlo con todas las entradas del usuario. Si estoy buscando un cliente por su nombre y tengo una consulta como

Select * from Customer Where Name like '%userInput%'

Si configuro userInput como una versión con hash de lo que se escribió, no funcionaría correctamente, incluso si Name también estuviera en la base de datos, solo funcionaría para la consulta de búsqueda exacta. Entonces, si tuviera un cliente con el nombre "Sue" y escribiera una búsqueda de "demandar", no funcionaría. Tampoco sabría el nombre de los clientes a menos que haya una coincidencia exacta en mi búsqueda, lo cual no es práctico.

La forma en que desea evitar la inyección de SQL es no hacer las consultas como se mencionó anteriormente, querrá procesar y parametrizar entradas en una consulta, eliminando cosas como = sy otros símbolos que no tienen sentido en contexto de la entrada. Puede encontrar una buena guía para prevenir la inyección de SQL aquí .

Básicamente, sí, si hash input (representado en formato Hex o Base64) antes de pasarlo a SQL, ya no puede ser un vector de ataque de SQLi efectivo. Lo mismo ocurre si parseInt la entrada. Esos simplemente no admiten los caracteres necesarios para un SQLi útil. (a saber, romper la cadena entre comillas)

Esta técnica tiene una utilidad limitada en la práctica. es decir, no sería compatible con algunas de las características de SQL famosas como LIKE , < , > ,
o búsquedas de igualdad indexadas ( = y <> usando índice)

Como nota al margen, señalaría que los hashes de contraseña realmente debe ser salado . Si se cumplieran esos criterios en su ejemplo, entonces creo que ya no estaría incluyendo un hash en la cláusula de SQL WHERE .

Lo que está haciendo (inadvertidamente) es parte de lo que se conoce como "sanear su información", que son pasos que todas las aplicaciones deben tomar para reducir defectos (y, por lo tanto, vulnerabilidades).

Una aplicación primero debe garantizar que la entrada no pueda desbordar la capacidad de la aplicación para aceptar datos. Eso podría significar una verificación de la longitud de la entrada o el rechazo de datos de gran tamaño.

A continuación, la aplicación debe verificar la entrada en una lista blanca, si es posible, para asegurarse de que ninguna entrada no deseada pueda ingresar a la lógica. En algunos casos, esto podría significar que la entrada solo contenga caracteres alfanuméricos válidos. Pero a veces una lista blanca no tiene sentido para ese campo de entrada en particular, sin embargo, el desarrollador todavía necesita evitar la inyección, por lo que incorporan una lista negra. La lista negra valida que la entrada no contiene símbolos conocidos para hacer posible la inyección. El inconveniente de las listas negras es que solo protegen contra lo que el desarrollador sabe bloquear. Un ejemplo podría ser una lista negra que detiene una comilla para evitar la inyección de SQL; pero es posible que el desarrollador no reconozca cuando la entrada pasa a través de la URL codificada que un% 27 se convertirá en una comilla.

Internamente, la aplicación debe escribirse a la defensiva para protegerse contra varias formas de inyección. El uso de SQL parametrizado (en lugar de construir una consulta SQL mediante concatenación) ayuda a prevenir la inyección de SQL. Pero muchos otros lugares donde las entradas de los usuarios pueden ser vulnerables a diferentes tipos de inyección. Las rutas de directorio pueden verse afectadas si un atacante ingresa algo como "..\..\..\..\..\..\windows\cmd.exe" Las consultas de XPath pueden inyectarse para manipular datos no autorizados. Y JavaScript puede pasar todo el camino a través de la base de datos para manipular el navegador de la víctima. Otras formas de defensa incluyen no revelar mensajes de error de diagnóstico interno en la salida y el registro para ayudar a identificar posibles atacantes.

Lo que su aplicación ha hecho es pasar primero la entrada a una rutina de hash, que tiene el doble efecto de sanear los datos y limitar su longitud antes de que llegue al paso de SQL. Solo tenga en cuenta que la entrada a la rutina de hash puede ser vulnerable a un desbordamiento de búfer. ¿Qué sucede cuando un atacante ingresa una contraseña de "aaaa[...repeated 1000 times...]aaaa_Evil_Injection_Here" ? Tu aplicación todavía necesita manejarlo.

Al igual que muchos otros estudiantes, estás confundiendo a el almacenamiento y el transporte . Y para proteger a este último, estás destruyendo deliberadamente al primero.

Debe comprender que la inyección de SQL no se denomina "inyección de base de datos" por una razón. No tienes que proteger la base de datos, el almacenamiento. Todo lo que necesita proteger es el transporte, la consulta SQL. Si bien su almacenamiento debería poder almacenar los datos tal como están , o no tendrá ningún valor. Si aún necesita alguna prueba para esa declaración,

• podría haber diferentes clientes, que no tienen idea de su "protección" elaborada en casa
• no solo existe una comparación estricta, y no solo una comparación: hay infinidad de afirmaciones en las que podrían participar sus datos: aritmética, búsqueda de subcadenas, varias conversiones, manipulaciones de cadenas y cálculos de todo tipo
• una base de datos no solo se utiliza para almacenar sus datos, sino también para manipularlos. Intente ordenar sus nombres de usuario con hash
• después de todo, a veces necesita volver a imprimir los datos desde una base de datos.

Por lo tanto, puede decir que cualquier medida de protección que cambie los datos almacenados de cualquier forma es simplemente errónea. Y tu idea simplemente no está bien pensada.

El hash protege la inyección de SQL del campo de contraseña en virtud del paso que codifica su salida binaria en una cadena.

Esta protección normalmente es inútil pero es suficiente si las siguientes suposiciones son ciertas:

• Su aplicación no maneja cadenas en ningún lugar, excepto el nombre de usuario y la contraseña.
• Se elimina el nombre de usuario de los caracteres ' y \ .

Si alguno de estos no es cierto o puede que lo sea en el futuro, el hash no es una defensa útil. Esto elimina el 99.9% de las aplicaciones web.