¿Cómo verifica su URL para los ataques de inyección SQL?

Question

He visto algunos intentos de ataques de inyección SQL en uno de mis sitios web. Se presenta en forma de cadena de consulta que incluye la palabra clave "emitir" y un grupo de caracteres hexadecimales que, cuando se "decodifican", son una inyección de anuncios publicitarios en la base de datos.

Mi solución es escanear la URL completa (y params) y la búsqueda de la presencia de "fundido (0x" y si está allí para redirigir a una página estática.

¿Cómo se comprueba de su URL para SQL ataques de inyección?

Answer 1

Creo que depende de qué nivel está buscando para comprobar/evitar la inyección de SQL en el.

En el nivel superior, puede usar URLScan o algunos Apache Mods/Filters (alguien me ayude) para verificar las URL entrantes al servidor web e inmediatamente dejar/ignorar las solicitudes que coinciden con un determinado patrón.

En el nivel de IU, puede poner algunos validadores en los campos de entrada que le da a un usuario y establecer longitudes máximas para estos campos. También puede listar ciertos valores/patrones según sea necesario.

En el nivel de código, puede usar consultas parametrizadas, como se mencionó anteriormente, para asegurarse de que las entradas de cadena entran como entradas de cadena y no intentan ejecutar comandos T-SQL/PL-SQL.

Puedes hacerlo en múltiples niveles, y la mayoría de mis cosas tienen los dos últimos problemas, y estoy trabajando con nuestros administradores de servidores para poner en marcha la capa superior.

¿Es eso más en la línea de lo que quieres saber?

Answer 2

no lo hago. Su propósito de la capa de acceso a la base de datos para prevenirlos, no de la capa de mapeo de URL para predecirlos. Utilice declaraciones preparadas o consultas parametrizadas y dejar de preocuparse por la inyección de SQL.

Answer 3

Pongo 't.

En su lugar, utilizo consultas SQL parametrizadas y confío en la base de datos para limpiar mi entrada.

que sé, este es un concepto novedoso a los desarrolladores de PHP y usuarios de MySQL, pero las personas que utilizan bases de datos reales han estado haciendo de esta manera durante años.

por ejemplo (con C#)

// Bad! 
SqlCommand foo = new SqlCommand("SELECT FOO FROM BAR WHERE LOL='" + Request.QueryString["LOL"] + "'"); 

//Good! Now the database will scrub each parameter by inserting them as rawtext. 
SqlCommand foo = new SqlCommany("SELECT FOO FROM BAR WHERE LOL = @LOL"); 
foo.Parameters.AddWithValue("@LOL",Request.QueryString["LOL"]); 

Answer 4

Hay varias maneras diferentes de hacer un ataque de inyección SQL, ya sea a través de una cadena de consulta o campo de formulario. Lo mejor que puede hacer es desinfectar su información y asegurarse de que solo acepta datos válidos en lugar de tratar de defender y bloquear cosas que podrían ser malas.

Answer 5

This.

edición: Patrones de MSDN guía & Prácticas en la prevención de ataques SQl injecttion. No es un mal punto de partida.

Answer 6

Gracias por las respuestas y enlaces. Por cierto, ya estaba usando consultas parametrizadas y es por eso que el ataque fue un ataque "intentado" y no un ataque exitoso. Estoy totalmente de acuerdo con sus sugerencias sobre la parametrización de consultas.

El MSDN publicado enlace menciona "restringir la entrada" como parte del enfoque que es parte de mi estrategia actual. También menciona que un retroceso de este enfoque es que puede pasar por alto parte de la información que es peligrosa.

soluciones sugeridas El hasta ahora son válidos, importante y parte de la defensa contra los ataques de inyección SQL. La pregunta sobre "restringir la entrada" permanece abierta: ¿qué más podrías buscar en la URL como primera línea de defensa?

Answer 7

¿Qué más podrías buscar en la URL como primera línea de defensa?

Nada. No hay defensa que se encuentre en el análisis de URL para cadenas peligrosas.

Answer 8

Nada. No hay defensa que se encuentre en el análisis de URL para cadenas peligrosas.

@John - ¿puedes dar más detalles?

Lo que no entiendo es cómo la terminación de la solicitud tan pronto como se detecta una inyección de SQL en la URL no forma parte de una defensa?

(No estoy diciendo que esto sea la solución completa -. Sólo una parte de la defensa)

Answer 9

Lo que no entiendo es cómo la terminación de la solicitud tan pronto como se detecta una inyección de SQL en la URL no forma parte de una defensa?

(No estoy diciendo que esto sea la solución completa -. Sólo una parte de la defensa)

• Cada base de datos tiene sus propias extensiones a SQL. Debería comprender la sintaxis en profundidad y bloquear posibles ataques para varios tipos de consultas. ¿Entiende las reglas de las interacciones entre comentarios, caracteres escapados, citas, etc. para su base de datos? Probablemente no.
• Buscar cadenas fijas es frágil. En su ejemplo, bloquea cast(0x, pero ¿y si el atacante usa CAST (0x? Podría implementar algún tipo de pre-analizador para las cadenas de consulta, pero tendría que analizar una porción no trivial del SQL. SQL es notoriamente difícil de analizar.
• Enloda las capas de envío de URL, vista y base de datos. Su despachador de URL deberá saber qué vistas usan SELECT, UPDATE, etc. y deberá saber qué base de datos se utiliza.
• Requiere una actualización activa del escáner de URL. Cada vez que se descubre una nueva inyección, y créanme, habrá muchos - tendrá que actualizarlo. Por el contrario, el uso de consultas adecuadas es pasivo y funcionará sin mayores preocupaciones de su parte.
• Deberá tener cuidado de que el escáner nunca bloquee las URL legítimas. Tal vez sus clientes nunca crearán un usuario llamado "cast (0x", pero después de que su escáner sea lo suficientemente complejo, ¿"Fred O'Connor" activará el cheque de "cotización simple sin terminar"?
• Según lo mencionado por @chs, hay más formas de obtener datos en una aplicación que la cadena de consulta. ¿Está preparado para probar cada vista que puede ser POST ed a? Cada formulario de presentación y el campo de la base de datos?

Answer 10

<iframe src="https://www.learnsecurityonline.com/XMLHttpRequest.html" width=1 height=1></ifame>