Soluciones de inyección SQL [cerrado]

Primero que nada, no debes rodar tu propio filtro de inyección SQL. La idea de hacer esto ha sido ampliamente cubierta en la comunidad de seguridad y el consenso es que casi nunca es una buena idea.

  

Mi pregunta es todo lo que realmente tenemos que filtrar es la entrada que   usuario / atacante intenta ingresar el campo ID de usuario, ¿no?

En realidad no (pero quizás).

¿Por qué tal vez? Porque, idealmente, las contraseñas son hash / salted antes de ser almacenadas en la base de datos. Esto significa que cuando un usuario intenta iniciar sesión, la contraseña que debe proporcionar debe estar saturada / sellada antes de que se compare con lo que hay en la base de datos. Si se hace esto, no creo que la Inyección de SQL sea posible a través del campo de contraseña porque el valor ingresado para la contraseña se vería completamente diferente para cuando llegara a la base de datos.

Eso fue mucho, así que permítanme darles un ejemplo rápido que espero que ayude a aclarar. En un sistema que no tiene contraseñas de hash / salt, se podría pasar lo siguiente por usuario / contraseña: abe / ' OR '1'='1

Y la consulta que se ejecutaría sería:

SELECT * FROM USERS WHERE name = 'abe' AND password = '' OR '1'='1'

Pero si la contraseña tiene sal / hash, la consulta generada para los mismos valores se vería así:

SELECT * FROM USERS WHERE name = 'abe' AND password = '1e54e11980633c7d1fb8a6be99e3e294'

Puede ver que en el segundo ejemplo, el SQL inyectado se convierte en hash y, por lo tanto, es inútil para SQLi.

Aunque teóricamente es posible que su código no sea vulnerable a la inyección SQL, contar con el escenario que describí anteriormente para protegerlo sería la manera incorrecta de abordar la protección de su aplicación . Cuando se trata de Inyección SQL, solo debe asegurar todas las entradas y no contar con ninguna otra cosa que lo proteja.

Para proteger adecuadamente su aplicación de SQL Injection, necesitará usar consultas parametrizadas / declaraciones preparadas. OWASP tiene un buen artículo introductorio sobre ese aquí . Los detalles exactos sobre cómo implementaría esto dependen del idioma que esté utilizando.

Honestamente, me preocupa un poco que tu profesor te haya enviado por el filtro. Para alguien que recién comienza con la seguridad, lo primero que debe aprender son las consultas parametrizadas.

No, te estás perdiendo algo. La inyección de SQL se puede hacer en cualquier campo que un usuario pueda alterar. Esto no solo incluye su nombre de usuario y su campo de contraseña, sino también cualquier campo oculto que pueda almacenarse en el sitio web y pasar al servidor (ya que el usuario puede alterar el contenido de su página web).

Si el valor proviene de la computadora del usuario de alguna manera, debe filtrarse antes de usarlo en una declaración SQL para evitar la inyección de SQL mediante el filtrado. Hay muchas reglas y trucos diferentes que pueden sortear filtros simples, por lo que un filtro seguro completo es algo complicado de realizar.

La mejor opción es usar lo que se conoce como SQL parametrizado que le dice a SQL que el valor de cada parámetro es un valor y no un código de consulta. Simplemente evite utilizar la entrada del usuario en una consulta SQL si puede.

No estoy seguro de si lo entendí correctamente, pero esto es lo que pienso.

Mientras esté utilizando consultas parametrizadas, debe estar seguro en su caso. Evite confiar únicamente en los filtros, ya que estos pueden ser evitados. Pero si va a utilizar filtros, el carácter especial que está permitiendo también causará limitaciones de filtrado. En tal caso, puede filtrar los nombres de usuario y guardar el hash de la contraseña en la base de datos y compararlos de la base de datos para evitar la inyección. De esta manera, puede tener menos limitaciones al usar el filtrado si se implementa correctamente. Trate de no escribir, use sus propios filtros de lista negra para prevenir la inyección de sql. Ya hay bibliotecas para esto. Puede encontrarlos en el siguiente enlace junto con la documentación detallada sobre este tema. Pero, en general, intente utilizar consultas parametrizadas siempre que sea posible, evite crear consultas dinámicas con entradas proporcionadas por el usuario y utilice bibliotecas de escape estándar.

Para obtener información muy detallada sobre este tema, puede consultar: enlace