security - tag - meta content

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

Question

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

FYI lo estoy usando con un DB de acceso. (No escribí la aplicación)

Answer 1

"Una forma sólida de protegerse contra la inyección de sql para una aplicación ASP clásica" es validar despiadadamente 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 usan en una consulta. ESO es lo que deberías estar buscando.

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

Answer 2

Aquí hay un par de scripts 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

Cambiar a SQL Express por lo menos 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 recomiendo que valide las entradas cuidadosamente para asegurarse de que coincidan con lo que está esperando.

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

Answer 4

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

Answer 5

Oye, cualquier base de datos y desarrollador que la use.

Nada más pero nada menos.

Si es un buen desarrollador puede construir 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 le irá bien para pequeñas empresas como la fabricación de joyas personalizadas a domicilio.

Y si es un buen desarrollador, no usará enunciados 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 la codificación html, es la mejor manera de prevenir cualquier ataque de inyección SQL.

Answer 6

Procedimientos almacenados y / o declaraciones preparadas:

https://.com/questions/1973/what-is-the-best-way-to-avoid-sql-injection-attacks

¿Puedo protegerme contra la inyección de SQL escapando la comilla simple y la entrada del usuario circundante 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 debe 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 normalmente 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 cierta manera para construir el código dinámico. En general, prefiero los SP porque forman una capa de interfaz que las aplicaciones obtienen en la base de datos, por lo que las aplicaciones ni siquiera pueden 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, por ejemplo, esto todavía es 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 tablas, cualquier código en esas aplicaciones (o aplicaciones comprometidas) puede ser un problema potencial. Si los inicios de sesión solo tienen derechos para ejecutar procedimientos almacenados, esto forma un embudo a través del cual puede garantizar con mayor facilidad el comportamiento correcto. (Similar a los conceptos OO donde los objetos son responsables de sus interfaces y no exponen todo su funcionamiento interno).

Answer 7

Usando consultas parametrizadas, necesita 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 (en referencia a la inyección de SQL por supuesto;))

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

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

Answer 8

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