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

Question

Ayer estaba hablando con un revelador, y mencionó algo acerca de la restricción de las inserciones en el campo de la base de datos, como, cadenas como -- (minus).

Al mismo tipo, lo que sé es que es un buen método para escapar de caracteres HTML, como <, etc. No > --. ¿Es esto cierto? ¿Hay que preocuparse por --, ++? Es más como un mito o cosas viejas?

---

Actualizar

Muchas gracias por todas las respuestas, es fácil de entender así desde que soy una especie de nuevo en todo esto. Bueno, para ser más específico, en este caso nuestra discusión estaba a punto y el sitio web de C # ASP.NET MVC que estamos desarrollando, por lo que hay un complejo de abrir una cuenta en forma allí con información importante, así que no estoy seguro de si MVC usando LINQ to interfaz con la base de datos ya viene con este tipo de protección o no. Así que si alguien podía proporciona algunas pistas sobre ella, sería muy bueno. Gracias de nuevo

Answer 1

La forma correcta para evitar ataques de inyección SQL no es simplemente no ciertos caracteres problemáticos, pero en lugar de usar SQL con parámetros. En resumen, SQL parametrizada impide la ejecución de la base de datos de entrada del usuario en bruto como parte del comando SQL esto impide la entrada del usuario como "tabla de la gota" de ser ejecutado. Sólo escapar caracteres no se detiene todas las formas de ataques de inyección SQL y la exclusión de ciertas palabras como "Drop" no funciona en todos los casos; no puede haber ciertos campos donde "gota" es una parte perfectamente válida de la entrada de datos.

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

https: //blog.codinghorror. com / give-me-parametrizada-sql-o-dar-me-muerte /

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

Ahora que usted ha mencionado que se está trabajando con ASP.net Te puedo dar algunos enlaces que se ocupan específicamente de inyección SQL 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 en la fabricación de su ASP más seguro: http://www.codeproject.com/KB/web-security/Securing_ASP_NET_Apps. aspx

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

Answer 2

Inyección SQL es un alto riesgo de seguridad para la mayoría de los sitios web que permiten a los usuarios a chorro parámetros en una declaración que se ejecuta en una base de datos.

Un ejemplo sencillo sería:

Campo de entrada "Nombre: _________

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

Así que si el tipo de "Bob" tenemos

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

Pero si escribo en "'; DROP TABLE tblCustomer", nos encontramos con el lugar más siniestro

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

Hay un montón de maneras de evitar estos problemas, y muchos se construyen en cualquier idioma que está utilizando - por lo que en lugar de pensar en todas las posibilidades poco fiables ";", "-", "/ *", etc, tratar de utilizar algo que ya existe.

grito hacia fuera el idioma que está utilizando y estoy seguro de que podemos decirle cómo evitar estos ataques.

Answer 3

Se refería a los ataques SQL Injection , como es bastante razón en lo que dijo.

El problema no es con dichos datos existentes en la base de datos, pero al pasar los datos de entrada directamente a la base de datos sin esterilizarlo.

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

Es difícil evitar totalmente, pero si se utiliza una buena biblioteca DB de su código y sigue las prácticas conocidas, tales como el uso de consultas paremeterized que limitar los posibles daños.

almacenar tantos -- en su base de datos como desee, pero no pasa que a través de su base de datos sin pasar por un proceso de limpieza (aquí es donde una buena biblioteca DB es vital - que debería cotizaciones de limpieza y alguna entrada potencialmente perjudiciales) .

Answer 4

No hay nada "peligroso" sobre la inserción de una cadena que contiene -- en una base de datos.

Es peligroso para insertar lo en una tabla de base de datos que viene directamente de la entrada del usuario sin procesarlo, de lo contrario se expone usted a ataques de inyección SQL . Ejemplo: Un codificador permite que el tipo de usuario a su nombre en un campo, y los tipos de usuario:

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

y luego el codificador pone que 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 la base de datos de inicio de sesión tenía los derechos para hacerlo, lo que no debería hacerlo - pero eso es otro tema), ya que el codificador no garantizaba que la cadena del usuario se escapó correctamente, por lo que fue expulsado directamente al motor de base de datos y el atacante tiene una buena risa. : -)

Utilice todas las herramientas a su entorno proporciona para asegurarse de que las cadenas se escaparon correctamente. Por ejemplo, JDBC utiliza la clase PreparedStatement para esto. La mayoría de los entornos tendrán algo similar.

Answer 5

Utilice consultas con parámetros. Estas consultas representan las variables como un marcador de posición en el SQL, como select * from person where name = ?. Después de crear la consulta SQL, configurar los valores de los parámetros en la consulta. consultas con parámetros aseguran que todo lo que fue sustituido por el marcador de posición, no serán considerados como parte de la instrucción SQL.

Jeff Atwood del artículo para una buena visión general de consultas con parámetros.

Answer 6

No es peligroso, siempre y cuando a escapar correctamente los datos al hacer INSERT / UPDATE /...

Y escapar caracteres HTML es un buen enfoque NO. Imagínese que usted escribió una función que escapa a estos personajes y que ha almacenado un texto escapado en la base de datos. Luego te das cuenta de que su función no escapó '<', por lo que cambia la función ... ahora lo que sucede con los registros que ya están en la base de datos? - Sus caracteres '<' se quedarán sin escapar. Por lo tanto, nunca escapar de texto antes de almacenarlos en la base de datos (escapar la consulta SQL, por supuesto). Escapar debe ocurrir cuando el código HTML / XML / ... página se produce a partir del texto, es decir, después de consultar el texto original de la base de datos!