Recientemente he heredado un sitio web asp clásico con un montón de instrucciones de inserción de SQL en línea que son vulnerables a los ataques de inyección de SQL.Inyección de ASP SQL clásica
Estas instrucciones de inserción se ejecutan a través del objeto de comando ADO.
Establecer la propiedad Preparado del objeto de comando ADO en verdadero, ¿se asegura que la consulta se parametrice antes de la ejecución, lo que mitiga el riesgo de inyección SQL?
Este enlace debería ser útil.
No, si crea una cadena SQL con valores que obtiene directamente de "afuera", entonces una "declaración preparada" no lo ayudará.
un
sSQL = "SELECT * from mytable where mycolumn = '" + querystring("value") + "'"
todavía es buscar problemas. La única forma de resolver esto es mediante el uso de parámetros en su consulta.
Lo que sugeriría que hacer es escribir una función para desinfectar la entrada del usuario, a continuación, ejecutar todas las variables de peticiones a través de eso. Cuando escribí el mío lo hice cosas como:
inyección SQL La mayoría intentaría algo así como ' or 1=1 or a=' lo que el código SQL sería:
SELECT * from mytable where mycolumn = '' or 1=1 or a=''
Así que escapan comillas simples es el verdadero grande que necesita para preocuparse.
Mucha gente cae en esa trampa. La creación de funciones hace que el código sea menos legible y no es a prueba de futuro. No tengo manera de rastrear todos los sitios ASP clásicos que construí hace años, y mucho menos actualizar una función que pueden o no estar usando. Los parámetros ADO o los procedimientos almacenados paramterizados son el camino a seguir. –
acepto que los parámetros son las mejores prácticas, pero si trata de limpiar una gran cantidad de código muy rápido, entonces es más fácil envolver todas las entradas de usuario en una función –
No creo que lleve mucho tiempo agregar un montón de 'oCmd.Parameters .Appende las sentencias oCmd.CreateParameter (...) 'a su código, y honestamente en situaciones como esta, creo que es mejor que se concentre en la calidad en lugar de la velocidad, particularmente si no tiene tiempo para hacer el trabajo dos veces. –
También puede ver un proyecto de código abierto ASP clásico llamado 'Owasp stinger'. Eso no solo ayuda con la inyección Sql, sino también con la inyección de encabezados y muchos otros problemas de seguridad comunes a todas las aplicaciones web.
+1 para el owasp :) – gmaran23
Aquí hay otro buen enlace y el ejemplo.
http://blogs.iis.net/nazim/archive/2008/04/28/filtering-sql-injection-from-classic-asp.aspx
En el pasado que acabamos de crear un par de funciones para manejar cualquier entrada exterior para inyecciones SQL y XSS. Luego, lentamente, convertimos todos los SQL en línea a procedimientos almacenados.
posible duplicado de [Protección de inyección SQL ASP clásica] (http://stackoverflow.com/questions/149848/classic-asp-sql-injection-protection) – NotMe