¿Cómo puedo evitar los ataques de inyección SQL?

Ayer estaba hablando con un desarrollador, y él mencionó algo sobre restringir las inserciones en el campo de la base de datos, como, cadenas como -- (menos menos).

En el mismo tipo, lo que sé es que es un buen enfoque para escapar caracteres HTML como < , > etc. No -- . ¿Es esto cierto? ¿Debo preocuparme por -- , ++ ? ¿Es más como un mito o cosas viejas?


Actualizar

Muchas gracias por todas las respuestas, es fácil de entender así ya que soy algo nuevo en todo esto. Bueno, para ser más específicos, en este caso nuestra discusión fue sobre el sitio web C # ASP.NET MVC que estamos desarrollando, así que hay un formulario de cuenta abierto complejo con información importante, así que no estoy seguro de si MVC usará Linq para la interfaz con la base de datos ya viene con este tipo de protección o no. Entonces, si alguien pudiera dar algunos consejos al respecto, sería genial. Gracias de nuevo

La forma correcta de evitar los ataques de inyección SQL no es simplemente rechazar ciertos caracteres problemáticos, sino utilizar SQL parametrizado. En resumen, el SQL parametrizado evita que la base de datos ejecute la entrada del usuario sin procesar como parte del comando SQL, lo que impide que se ejecute la entrada del usuario, como “drop table”. El solo hecho de escapar de los caracteres no detiene todas las formas de ataques de inyección SQL y excluye ciertas palabras, como “Eliminar”, no funciona en todos los casos; puede haber ciertos campos donde “Drop” es una parte perfectamente válida de la entrada de datos.

Puede encontrar algunos buenos artículos sobre el tema de SQL patwigterizado aquí:

https://blog.codinghorror.com/give-me-parameterized-sql-or-give-me-death/

http://www.codeproject.com/KB/database/ParameterizingAdHocSQL.aspx

Ahora que mencionaste que estás trabajando con ASP.net puedo darte algunos enlaces que tratan específicamente con SQL Injection en ASP.

https://dzone.com/articles/aspnet-preventing-sql-injectio http://www.codeproject.com/KB/aspnet/SQL_Injection_.aspx?msg=3209511

Aquí hay un artículo más general sobre cómo hacer que su ASP sea más segura: http://www.codeproject.com/KB/web-security/Securing_ASP_NET_Apps.aspx

Y, por supuesto, el artículo de MSDN sobre inyección de SQL: http://msdn.microsoft.com/en-us/library/ms998271.aspx

La inyección SQL es un riesgo de alta seguridad para la mayoría de los sitios web que permite a los usuarios aplicar parámetros en una statement que se ejecuta en una base de datos.

Un ejemplo simple sería:

Campo de entrada “Nombre: _________

 "SELECT * FROM tblCustomer WHERE Name = '" + nameInputField + "'" 

Entonces, si escribo “Bob” tenemos

 "SELECT * FROM tblCustomer WHERE Name = 'Bob'" 

Pero si escribo “‘; DROP TABLE tblCustomer”, terminamos con el bastante más siniestro

 "SELECT * FROM tblCustomer WHERE Name = ''; DROP TABLE tblCustomer" 

Hay muchas maneras de evitar estos problemas, y muchas están integradas en cualquier idioma que esté utilizando, así que en lugar de pensar en todas las posibilidades poco fiables “;”, “-“, “/ *”, etc., intente utilizar algo que ya existe.

Grite qué idioma está usando y estoy seguro de que podemos decirle cómo evitar estos ataques.

Use consultas parametrizadas. Estas consultas representan las variables como un marcador de posición en el SQL, como por ejemplo select * from person where name = ? . Después de crear la consulta SQL, establece los valores de los parámetros en la consulta. Las consultas parametrizadas garantizan que lo que se sustituyó por el marcador de posición no se considerará como parte de la statement de SQL.

Consulte el artículo de Jeff Atwood para obtener una buena visión general de las consultas parametrizadas.

Estaba hablando de ataques de inyección SQL , ya que tiene razón en lo que dijo.

El problema no es que esos datos estén en la base de datos, sino que se transfieren datos de entrada directamente a la base de datos sin desinfectarlos.

Sin limpiarlo, si alguien pasa una cadena que termina con a ; luego pueden seguirlo con lo que quieran ( select * from sys.objects , por ejemplo) o algo más malicioso, como dejar caer algunas tablas.

Es difícil evitarlo por completo, pero si utiliza una buena biblioteca de BD de su código y sigue las prácticas conocidas, como el uso de consultas parametrizadas, limita el posible daño.

Almacene tantas cosas en su base de datos como desee, pero no las transfiera a su base de datos sin pasar por un proceso de limpieza (aquí es donde una buena biblioteca de BD es vital, debe incluir citas de limpieza y otras entradas potencialmente dañinas).

No hay nada “peligroso” en insertar una cadena que contenga -- en una base de datos.

Es peligroso insertar cualquier cosa en una tabla de base de datos que provenga directamente de la entrada del usuario sin procesarlo, de lo contrario, usted se abrirá a ataques de inyección de SQL . Ejemplo: un codificador le permite al usuario escribir su nombre en un campo y el usuario escribe:

 Joe '); drop table users; commit transaction; -- 

y luego el codificador pone eso en su base de datos MySQL así:

 conn.execute("insert into users (username) values ('" + userInput + "')"); 

Boom El usuario ha eliminado la tabla de usuarios (suponiendo que el inicio de sesión de la base de datos tuviera derechos para hacerlo, lo cual no debería ser, pero ese es un tema diferente), porque el codificador no se aseguró de que la cadena del usuario se haya escapado correctamente, y así fue enviado directamente al motor de DB y el atacante se rió mucho. 🙂

Use las herramientas que su entorno proporcione para garantizar que las cadenas se escapen correctamente. Por ejemplo, JDBC usa la clase PreparedStatement para esto. La mayoría de los entornos tendrán algo similar.

No es peligroso siempre que escape correctamente los datos al hacer INSERT / UPDATE / …

Y escaparse de los caracteres HTML NO es un buen enfoque. Imagine que ha escrito una función que escapa de dichos caracteres y ha almacenado algún texto escapado en la base de datos. Luego observa que su función no escapó a ‘<', por lo que cambia la función ... ¿qué pasa con los registros que ya están en la base de datos? - Sus caracteres '<' permanecerán sin protección. Por lo tanto, NUNCA escape el texto antes de almacenarlo en la base de datos (escape de la consulta SQL, por supuesto). Se debe escapar cuando la página HTML / XML / … se produce fuera del texto, es decir, después de consultar el texto original de la base de datos.

    Intereting Posts