Si desde una consulta SQL elimino todos los 'caracteres, ¿hay alguna otra forma de hacer un ataque de inyección SQL en la base de datos?¿Hay alguna forma de inyectar SQL incluso si se elimina el carácter '?
¿Cómo se puede hacer? ¿Alguien puede darme ejemplos?
Sí, la hay. Un extracto de Wikipedia
"SELECT * FROM data WHERE id = " + a_variable + ";"
Se desprende de esta declaración que el autor pretende a_variable a ser un número correlación con el campo "id". Sin embargo, si de hecho es una cadena, el usuario final puede manipular la declaración como lo prefiera, sin tener en cuenta la necesidad de caracteres de escape. Por ejemplo, establecer a_variable a
1;DROP TABLE users
caerá (eliminar) la tabla "usuarios" de la base de datos, ya que el SQL quedaría como sigue:
SELECT * FROM DATA WHERE id=1;DROP TABLE users;
inyección SQL se no un ataque simple para luchar. Haría una investigación muy cuidadosa si fuera tú.
Sí, dependiendo del enunciado que esté utilizando. Es mejor protegerse a sí mismo mediante el uso de procedimientos almacenados, o al menos consultas parametrizadas.
Consulte WikiPedia para muestras de prevención.
Si pudiera modifiqué 1 billón de veces, lo haría. A menos que esté escribiendo el controlador/biblioteca que proporciona la parametrización, no puedo pensar en ninguna razón para siquiera considerar algo más para protegerme de la inyección de SQL. –
. . . uh sobre 50000000 otras formas
tal vez algo como 5; drop table employees; --
resultante de SQL puede ser algo como: select * from somewhere where number = 5; drop table employees; -- and sadfsf
(-- comienza un comentario)
Depende de cómo armar la consulta, pero en esencia sí.
Por ejemplo, en Java Si se va a hacer esto (ejemplo deliberadamente atroz):
String query = "SELECT name_ from Customer WHERE ID = " + request.getParameter("id");
entonces hay una buena probabilidad de que se está abriendo a un ataque de inyección.
Java tiene algunas herramientas útiles para protegerse de ellas, como PreparedStatements (donde pasa una cadena como "SELECT nombre_ del cliente DONDE ID =?" Y la capa JDBC maneja escapes mientras reemplaza los tokens por usted), pero algunos otros idiomas no son tan útiles para esto.
Sí, absolutamente: dependiendo de su dialecto SQL y tal, hay muchas maneras de lograr la inyección que no utilizan el apóstrofo.
La única defensa confiable contra los ataques de inyección SQL es el uso del soporte de declaración SQL parametrizado que ofrece su interfaz de base de datos.
Thing es la entrada tal vez genuina de un apóstrofo y debe escapar de ellos duplicándolos cuando usa SQL en línea en su código. Lo que se busca es un patrón de expresión como:
\;.*--\
Un punto y coma se utiliza para terminar prematuramente la declaración genuina, algunos SQL inyectado seguido de un guión doble para comentar el SQL de arrastre de la declaración original genuina. Los guiones pueden omitirse en el ataque.
Por lo tanto, la respuesta es: No, simplemente eliminar los apóstrofes no garantiza la seguridad de SQL Injection.
En lugar de intentar averiguar qué caracteres filtrar, me quedaría con las consultas parametrizadas y eliminaré el problema por completo.
Sí, es definitivamente posible.
Si usted tiene una forma en la que espera un entero a su próxima instrucción SELECT, entonces se puede introducir algo similar:
SELECT * FROM thingy DONDE attributeID =
users; (malo, malo, malo ...)El siguiente sitio web detalla otras técnicas clásicas de inyección SQL: SQL Injection cheat sheet.
El uso de consultas parametrizadas o procedimientos almacenados no es mejor. Estas son solo consultas pre-hechas usando los parámetros pasados, que también pueden ser una fuente de inyección. También se describe en esta página: Attacking Stored Procedures in SQL.
Ahora, si suprime la cita simple, evitará solo un determinado conjunto de ataques. Pero no todos ellos.
Como siempre, no confíe en los datos provenientes del exterior. Filtrarlos en estos 3 niveles:
Diviértete y no olvides marcar WikiPedia para obtener respuestas.
/Vey
Solo una nota de que el dominio que alberga el artículo "Ataque de procedimientos almacenados en SQL" ahora parece haber desaparecido. – Funka
También- incluso si usted sólo tiene que buscar el apóstrofe, que no quieren para eliminarlo. Desea escape. Lo haces reemplazando cada apóstrofo con dos apóstrofes.
Pero las consultas parametrizadas/procedimientos almacenados son mucho mejores.
SQL en línea parametrizada o procedimientos almacenados parametrizados es la mejor manera de protegerse.Como han señalado otros, simplemente pelar/escapar del carácter de comillas simples no es suficiente.
Notarás que hablo específicamente de procedimientos almacenados "parametrizados". Simplemente usar un procedimiento almacenado tampoco es suficiente si se vuelve a concatenar los parámetros pasados del procedimiento juntos. En otras palabras, envolver exactamente la misma declaración SQL vulnerable en un procedimiento almacenado no lo hace más seguro. Necesita usar parámetros en su procedimiento almacenado como lo haría con SQL en línea.
Solo puedo repetir lo que otros han dicho. SQL parametrizado es el camino a seguir. Claro, es un poco doloroso codificarlo, pero una vez que lo ha hecho una vez, entonces no es difícil cortar y pegar ese código y hacer las modificaciones que necesita. Tenemos una gran cantidad de aplicaciones .Net que permiten a los visitantes del sitio web especificar una amplia gama de criterios de búsqueda, y el código crea la declaración SQL Select sobre la marcha, pero todo lo que podría haber ingresado un usuario entra en un parámetro.
Le sugiero que pase las variables como parámetros y no cree su propio SQL. De lo contrario, siempre habrá una forma de hacer una inyección SQL, de maneras que actualmente desconocemos.
El código se crea es entonces algo así como:
' Not Tested
var sql = "SELECT * FROM data WHERE id = @id";
var cmd = new SqlCommand(sql, myConnection);
cmd.Parameters.AddWithValue("@id", request.getParameter("id"));
Si usted tiene un nombre como el mío con un "en ella. Es muy molesto que todos los caracteres 'se eliminen o marquen como inválidos.
También puede consultar este Stackoverflow question about SQL Injections.
Esto es sin duda una buena práctica –
Cuando espera un parámetro numérico, siempre debe estar validando la entrada para asegurarse de que sea numérica. Más allá de ayudar a proteger contra la inyección, el paso de validación hará que la aplicación sea más fácil de usar.
Si recibes id = "hello" cuando esperabas id = 1044, siempre es mejor devolver un error útil al usuario en lugar de dejar que la base de datos devuelva un error.
Dado que esta es una pregunta relativamente más antigua, no me molestaré en escribir una respuesta completa y completa, ya que la mayoría de los aspectos de esa respuesta han sido mencionados aquí por uno u otro cartel.
Creo que es necesario, sin embargo, mencionar otro problema que no fue abordado por nadie aquí: SQL Smuggling. En ciertas situaciones, es posible "contrabandear" el carácter de cotización en su consulta , incluso si intentó eliminarlo. De hecho, esto puede ser posible incluso si usó comandos adecuados, parámetros, procedimientos almacenados, etc.
Consulte el artículo completo de investigación en http://www.comsecglobal.com/FrameWork/Upload/SQL_Smuggling.pdf (declaración, yo era el investigador principal sobre esto) o simplemente google "SQL Smuggling ".
Cabe señalar que solo ocurre si su sistema le permite ejecutar múltiples consultas SQL a la vez. PHP 'mysql_query' no. – DisgruntledGoat