¿Cuáles son los problemas de las inyecciones de SQL de las consultas parametrizadas?

Question

¿Cuáles son los problemas de las inyecciones de SQL de las consultas parametrizadas?

#1 de Hendrik Brummermann (10 votos)
#2 de AviD (6 votos)

11

He escrito algún código para generar una consulta SQL en ASP clásico. No estoy seguro de si es seguro o no:

Set adoCon = Server.CreateObject("ADODB.Connection")
adoCon.Open "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & Server.MapPath(dbfile)
strSQL = "SELECT * FROM Table WHERE name_field LIKE ?"

Set cmd1 = Server.CreateObject("ADODB.Command") 
cmd1.ActiveConnection = adoCon 
cmd1.CommandText = strSQL 
cmd1.CommandType = 1 'adCmdText 
cmd1.Parameters(0) =  Request("odQuery") & "%"  
Set rs = cmd1.Execute()

Luego continúo para mostrar los resultados de rs .

¿Esto es seguro? (Sé que, por ejemplo, puedo poner un signo de porcentaje al comienzo de odQuery y hacer que el código devuelva más registros).

web-application appsec sql-injection databases classic-asp

pregunta Flash 15.08.2011 - 08:01

fuente

2 respuestas

Lea otras preguntas en las etiquetas web-application appsec sql-injection databases classic-asp

Código php ofuscado encontrado en el servidor ¿Qué problemas tiene este procedimiento de "recuperación de cuenta"?

score 10 · Answer 1

Ya está utilizando consultas parametrizadas que lo protegen contra la inyección de partes de SQL, asumiendo que siempre está utilizando parámetros para datos no confiables.

Como dijiste, deja el problema de los caracteres comodín en los operadores que los admiten. Es decir, si está utilizando "=" en lugar de LIKE, el problema no surgirá. En la mayoría de los casos, en los que LIKE se usa intencionalmente, se desea una búsqueda con datos proporcionados por el usuario. Por lo tanto, agregar más comodines no es un problema.

Sin embargo, la adición de un comodín en la parte frontal puede tener un impacto significativo en el rendimiento porque los índices de prefijo no se pueden usar de manera eficiente. Entonces, si su conjunto de datos es enorme, puede filtrarlos. Los comodines estándar son% y _, pero algunas bases de datos admiten caracteres adicionales como *.

score 6 · Answer 2

Esto no es seguro, por varias razones, que probablemente ni siquiera estás considerando.

Empecemos por la parte superior:

Estás utilizando ASP "clásico". Esta plataforma es conocida por ser insegura.
Su proveedor es Microsoft.Jet . Supongo que esto se está conectando a un archivo de MS Access ... Nuevamente, no es un backend seguro. P.ej. no hay autenticación en la base de datos, problemas con un archivo compartido, etc.
No sé si te das cuenta de esto, si es intencional o si incluso importa en tu aplicación , pero estás tomando el parámetro de Request("odQuery") , que podría ser Request.Forms("odQuery") , Request.QueryString("odQuery") , etc ... El atacante puede hacer un mal uso de esto, por ejemplo, al crear un enlace (en lugar de un POST) y hacer que otra persona (por ejemplo, con privilegios más altos) lo envíe.
Estoy especulando aquí, pero a juzgar por el código anterior (y el hecho de que este es el "ASP clásico"), " I then go on to display the results from rs " Supongo que es muy probable que resulte en XSS (secuencias de comandos entre sitios).
Ahora, hablemos de la inyección SQL, como @Hendrik señaló en su respuesta, los comodines son un problema. Esto puede tener 2 problemas:
- Acceso a datos a los que el usuario no debería tener acceso
- Crear un ataque de denegación de servicio (DoS, Denial of Service), al provocar búsquedas intensivas de gran capacidad computacional, como colocar el comodín al frente en grandes conjuntos de datos (como señaló @Hendrik).

Si está buscando específicamente una manera de ejecutar una consulta secundaria, está seguro de esto, al menos en Access (algunos beneficios de no usar una base de datos con todas las funciones ...).
Sin embargo, hay otras formas de inyección SQL (como las anteriores), e incluso más formas de ser inseguro.