Protección clásica de inyección de SQL ASP

Question

¿Cuál es una forma sólida de proteger contra la inyección de sql para una aplicación asp clásica?

FYI Lo estoy usando con una base de datos de acceso. (No escribí la aplicación)

Answer 1

Procedimientos almacenados y / o declaraciones preparadas:

https://stackoverflow.com/questions / 1973 / ¿cuál es la mejor manera de evitar los ataques de inyección SQL?

¿Puedo proteger? contra la inyección SQL escapando de comillas simples y rodeando la entrada del usuario con comillas simples

Captura de inyección SQL y otras solicitudes web maliciosas

Con Access DB, aún puede hacerlo, pero si ya está preocupado por la inyección SQL, creo que necesita salir de Access de todos modos.

Aquí hay un enlace a la técnica en Access:

http://www.asp101.com/samples/storedqueries.asp

Tenga en cuenta que lo que generalmente protege de la inyección no es el procedimiento almacenado en sí, sino el hecho de que está parametrizado y no es dinámico. Recuerde que incluso los SP que crean código dinámico pueden ser vulnerables a la inyección si usan parámetros de ciertas maneras para construir el código dinámico. En general, prefiero los SP porque forman una capa de interfaz que las aplicaciones llegan a la base de datos, por lo que a las aplicaciones ni siquiera se les permite ejecutar código arbitrario en primer lugar.

Además, el punto de ejecución del procedimiento almacenado puede ser vulnerable si no utiliza comandos y parámetros, p. esto sigue siendo vulnerable porque está construido dinámicamente y puede ser un objetivo de inyección:

Conn.Execute("EXEC usp_ImOnlySafeIfYouCallMeRight '" + param1 + "', '" + param2 + "'") ;

Recuerde que su base de datos necesita defender su propio perímetro, y si varios inicios de sesión tienen derechos para INSERT / UPDATE / DELETE en cualquier tabla, cualquier código en esas aplicaciones (o aplicaciones comprometidas) puede ser un potencial problema. Si los inicios de sesión solo tienen derechos para ejecutar procedimientos almacenados, esto forma un embudo a través del cual puede asegurar mucho más fácilmente un comportamiento correcto. (Similar a los conceptos OO donde los objetos son responsables de sus interfaces y no exponen todo su funcionamiento interno).

Answer 2

Aquí hay un par de scripts de sqlinject que hice hace mucho tiempo una versión simple y una versión extendida:

function SQLInject(strWords) 
dim badChars, newChars, i
badChars = array("select", "drop", ";", "--", "insert", "delete", "xp_") 
newChars = strWords 
for i = 0 to uBound(badChars) 
newChars = replace(newChars, badChars(i), "") 
next 
newChars = newChars 
newChars= replace(newChars, "'", "''")
newChars= replace(newChars, " ", "")
newChars= replace(newChars, "'", "|")
newChars= replace(newChars, "|", "''")
newChars= replace(newChars, "\""", "|")
newChars= replace(newChars, "|", "''")
SQLInject=newChars
end function 


function SQLInject2(strWords)
dim badChars, newChars, tmpChars, regEx, i
badChars = array( _
"select(.*)(from|with|by){1}", "insert(.*)(into|values){1}", "update(.*)set", "delete(.*)(from|with){1}", _
"drop(.*)(from|aggre|role|assem|key|cert|cont|credential|data|endpoint|event|f ulltext|function|index|login|type|schema|procedure|que|remote|role|route|sign| stat|syno|table|trigger|user|view|xml){1}", _
"alter(.*)(application|assem|key|author|cert|credential|data|endpoint|fulltext |function|index|login|type|schema|procedure|que|remote|role|route|serv|table|u ser|view|xml){1}", _
"xp_", "sp_", "restore\s", "grant\s", "revoke\s", _
"dbcc", "dump", "use\s", "set\s", "truncate\s", "backup\s", _
"load\s", "save\s", "shutdown", "cast(.*)\(", "convert(.*)\(", "execute\s", _
"updatetext", "writetext", "reconfigure", _
"/\*", "\*/", ";", "\-\-", "\[", "\]", "char(.*)\(", "nchar(.*)\(") 
newChars = strWords
for i = 0 to uBound(badChars)
Set regEx = New RegExp
regEx.Pattern = badChars(i)
regEx.IgnoreCase = True
regEx.Global = True
newChars = regEx.Replace(newChars, "")
Set regEx = nothing
next
newChars = replace(newChars, "'", "''")
SqlInject2 = newChars
end function

Answer 3

" Una forma sólida de proteger contra la inyección de sql para una aplicación asp clásica " es validar sin piedad todas las entradas. Período.

Los procedimientos almacenados solos y / o un sistema de base de datos diferente no necesariamente equivalen a una buena seguridad.

MS lanzó recientemente una herramienta de inspección de inyección SQL que busca entradas no validadas que se utilizan en una consulta. ESO es lo que deberías estar buscando.

Aquí está el enlace: La herramienta Microsoft Source Code Analyzer for SQL Injection está disponible para encontrar vulnerabilidades de inyección SQL en el código ASP

Answer 4

Usando consultas parametrizadas, debe crear un objeto de comando, asignarle parámetros con un nombre y un valor; si lo hace, no tendrá que preocuparse por nada más (refiriéndose a la inyección sql, por supuesto;))

http://prepared-statement.blogspot.com /2006/02/asp-prepared-statements.html

Y no confíe en los procedimientos almacenados, también pueden convertirse en un vector de ataque si no utiliza declaraciones preparadas.

Answer 5

si los procedimientos almacenados no son una opción, e incluso si lo son, valide todas las entradas a fondo

Answer 6

Hola, cualquier base de datos tan buena como el desarrollador que la usa.

Nada más pero nada menos.

Si es un buen desarrollador, puede crear un sitio de comercio electrónico utilizando archivos de texto como base de datos. Sí, no será tan bueno como el sitio web impulsado por Oracle, pero funcionará bien para las pequeñas empresas, como la fabricación de joyas personalizadas en el hogar.

Y si usted es un buen desarrollador, no utilizará declaraciones SQL en línea en sus páginas ASP. Incluso en Access tiene la opción de crear y usar consultas ...

Almacenar procs con verificación de datos, junto con codificación html, es la mejor manera de prevenir cualquier ataque de inyección SQL.

Answer 7

La Herramienta de inyección de Microsoft Source Code Analyzer para SQL está disponible para encontrar vulnerabilidades de inyección SQL en Código ASP

Answer 8

Cambiar a SQL Express como mínimo es una gran opción. Hará las cosas mucho más seguras. Aunque el uso de parámetros y procedimientos almacenados puede ser de gran ayuda. También le recomiendo que valide las entradas cuidadosamente para asegurarse de que coincidan con lo que espera.

Para valores como números, es bastante fácil extraer el número para verificar que de hecho es solo un número. Escapar de todos los caracteres especiales para SQL. Hacer esto evitará que el intento de ataque funcione.