El problema

Tenemos que defender contra una «WAITFOR DELAY’ ataque de inyección de sql en nuestra aplicación java.

Fondo

[Esto es, de largo. Skip to ‘Solución?’ sección, a continuación si usted está en un apuro ]

Nuestra aplicación en su mayoría utiliza declaraciones preparadas y exigible declaraciones (procedimientos almacenados) en el acceso a la base de datos.

En un par de lugares que dinámicamente construir y ejecutar consultas para la selección. En este paradigma, utilizamos un criterio de objeto a construir la consulta dependiendo del tipo de usuario-criterios de entrada. Por ejemplo, si el usuario especificado valores para el nombre y el apellido, el resultado de la consulta siempre se ve algo como esto:

SELECT first_name,last_name FROM MEMBER WHERE first_name ='joe' AND last_name='frazier'

(En este ejemplo, el usuario ha especificado «joe» y «frazier» como sus valores de entrada. Si el usuario tuviera más o menos criterio tendríamos más o menos consultas. Hemos encontrado que este enfoque es más fácil que el uso de declaraciones preparadas y más rápido/más eficientes que los procedimientos almacenados).

El ataque

Una vulnerabilidad de auditoría informó de una inyección sql fracaso. El atacante inyecta el valor ‘frazier WAITFOR DELAY ’00:00:20’ para el ‘last_name’ parámetro, resultando en este sql:

   SELECT first_name,last_name FROM MEMBER WHERE first_name ='joe' AND last_name='frazier' WAITFOR DELAY '00:00:20'

El resultado: la consulta se ejecuta correctamente, pero tarda 20 segundos en ejecutarse. Un atacante podría atar todos sus conexiones de base de datos en la db de la piscina y cerró efectivamente su sitio.

Algunas observaciones acerca de este ‘WAITFOR DELAY’ ataque

  • Yo había pensado que ya que hemos utilizado Declaración executeQuery(String) estaríamos a salvo de la inyección de sql. executeQuery(String) no se ejecutará DML o DDL (elimina o disminuye). Y executeQuery(String) estranguladores en punto y coma, por lo tanto el ‘Bobby Tablas de’ paradigma fallará (es decir, el usuario entra en ‘frazier; SOLTAR el miembro de la MESA’ para un parámetro. Ver. http://xkcd.com/327/)

  • El ‘WAITFOR’ ataque difiere en un aspecto importante: WAITFOR modifica la existente ‘SELECCIONAR’ comando, y no es un comando independiente.

  • El ataque sólo funciona en el ‘último parámetro’ en la consulta resultante. es decir, ‘WAITFOR’ debe ocurrir al final de la instrucción sql

Solución, Hoteles de Hack, o Ambos?

La solución más obvia implica simplemente atacado «and 1=1» en la cláusula where.

El sql resultante falla inmediatamente y previene el atacante:

   SELECT first_name,last_name FROM MEMBER WHERE first_name ='joe' AND last_name='frazier' WAITFOR DELAY '00:00:20' AND 1=1

Las Preguntas

  • Es esta una solución viable para la WAITFOR ataque?
  • Hace es defenderse de otros similares vulnerabilidades?
  • Creo que la mejor opción conllevaría el uso de declaraciones preparadas. Más trabajo, pero menos vulnerable.
lamentablemente, la única persona que láminas de ti mismo. Si usted tack, en lugar de la demora, «or 1=1», puede que al final permite a cualquier persona y todo el mundo para iniciar la sesión. No trate de engañar a sí mismo para pensar que puede llegar a ser más astuto que todos los que quieran intentar romper su sitio. Eres una persona, si su sitio es popular, son muchos. Si no, entonces probablemente no importa qué, si algo, hazlo.
regla #1: no sintetizar y ejecutar código desde fuentes no confiables…

OriginalEl autor user72150 | 2010-01-07

6 Comentarios

  1. 22

    La forma correcta de manejar la inyección de SQL es el uso de consultas parametrizadas. Todo lo demás es sólo mear en el viento. Podría funcionar de una vez, incluso dos veces, pero con el tiempo se recibe un golpe por esa cálida sensación que dice «jodido, mal!»

    Hagas lo que hagas, excepto consultas parametrizadas, va a ser sub-óptima, y será hasta usted para asegurarse de que su solución no tiene otros agujeros que usted necesita parche.

    Consultas parametrizadas, por otro lado, funciona fuera de la caja, y evita todos estos ataques.

    Buen punto, creo que tendría que haber sido más específico – una declaración preparada no va a hacer ningún bien si se le pasa una gran cadena concatenada en lugar de uno con el parámetro marcadores de posición!
    Es por eso que me dijo «consulta parametrizada», no «a la consulta preparada».
    «La forma correcta de manejar la inyección de SQL es el uso de consultas parametrizadas. Todo lo demás es sólo mear en el viento» Gracias por decir la verdad! Esta es la respuesta a casi cualquier seguridad de un problema de programación realidad.

    OriginalEl autor Lasse Vågsæther Karlsen

  2. 11

    La inyección de SQL es la inyección SQL, no hay nada especial acerca de un WAITFOR DELAY.

    No hay absolutamente ninguna excusa para no utilizar sentencias preparadas para una simple consulta en este día y edad.

    (Edit: Bueno, no «absolutamente» – pero hay casi nunca una excusa)

    mirando el código, varios de estos ‘finder’ DAO métodos de generar ‘EN las cláusulas’ (es decir, «DONDE el ESTADO (1,2,3)»). No hay excusas, pero estos son más difíciles con sentencias preparadas.
    De verdad que no. Sólo parametrizar el individuo EN tokens (WHERE status IN (?, ?, ?)).
    una arruga: el tamaño de la lista puede variar. dinámica de la lista de tamaños de presentar un problema, AFAIK la preparedStatement sql tiene una larga lista de ‘?’ (es decir, límite superior del tamaño de la lista); usted puede fijar los 3 primeros y el uso setNull para establecer el último límite superior-3. es decir, : DONDE el estado EN (?,?,?,?,?,?,?,?,?,?)
    Este es un problema resuelto: javaranch.com/journal/200510/Journal200510.jsp#a2 Cualquiera de esos métodos son mejores que las cadenas crudas.
    No, creo que es ‘absolutamente’. No hay excepciones. Cualquier cosa que usted piensa que es una excepción en realidad es algo que usted necesita para resolver de otra manera.

    OriginalEl autor Aaronaught

  3. 3

    Creo que sugirió la solución usted mismo: Consultas Parametrizadas.

    ¿Cómo usted encuentra que su dinámica de consulta es más rápido que usando un procedimiento almacenado? En general es a menudo lo contrario.

    Ah, sí. En general es cierto, pero en estos casos específicos que hemos encontrado de otra manera. He aquí la situación: usted tiene un método de DAO que tiene una especificación de los criterios objeto con 30 campos. Usted podría tener un procedimiento almacenado con 30 parámetros con sql que se parece a esto: SELECT apellidos, nombre DE miembro (@papellido ES NULO O @papellido=last_name) Y (@pFirstName ES NULO O @pFirstName= ‘ nombre) Y (@pSerialNbr ES NULO O @pSerialNbr=serial_nbr) Y (@pZodiacSign ES NULO O @pZodiacSign=zodiac_sign) Y (@pPartyRank ES NULO O @pPartyRank=party_rank)
    desde mi experiencia, el SQL de los optimizadores de motores de realizar muy mal en esos procedimientos; se re-uso muy genérica plan de acceso (normalmente completa-exploración de la tabla), en lugar de reconocer en el acto para el uso de un índice en particular . Además, algunos de los valores son, de hecho, las listas (es decir, ‘DONDE el rango (1,2,3)’ ). Tengo en lugares pasado en listas separadas por comas a un procedimiento almacenado, se analiza y se rellena una tabla temporal, y se unió en contra de la tabla temporal, pero esto en la práctica realiza MUCHO PEOR que un simple sql con una cláusula in.
    finalmente, para resumir, a partir de mi experiencia : sql simple funciona mejor. Super-lujo sql hace super-lenta. Optimizadores y acceso-plan-generadores no es tan inteligente. (también tenemos el apoyo de un par de diferentes db se lo han límites de cómo muchos consejos que podemos ofrecer)
    Si uno debe para ello el uso de SQL generadas dinámicamente, desinfectar la entrada. Por que me refiero a escapar de las cadenas, y la validación de los tipos numéricos, etc. Hay un montón de código pre-existente a hacer por usted.
    Los procedimientos almacenados no le protegerá contra inyección SQL si usted romper las cadenas juntos en el procedimiento almacenado a sí mismo y, a continuación, exec() el resultado. Yo he visto a este hecho. Lo importante a destacar es parametrizada consultas.

    OriginalEl autor Daniel Vassallo

  4. 2

    Para responder a todas sus preguntas:

    Es esta una solución viable para la WAITFOR ataque?

    No. Sólo añadir — para el ataque de la cadena y va a ignorar su corrección.

    Hace es defenderse de otros similares vulnerabilidades?

    No. Ver arriba.

    Creo que la mejor opción conllevaría el uso de declaraciones preparadas. Más trabajo, pero menos vulnerable.

    Sí. Usted no se soluciona con la inyección de SQL a ti mismo. Utilizar lo que ya existe y se utiliza de manera correcta, es decir, mediante la parametrización un cualquier parte dinámica de la consulta.

    Otro menor solución es escapar de cualquier cadena que se va a insertarse en la consulta, sin embargo, usted se olvidar que uno de día y usted sólo necesita uno para atacar.

    OriginalEl autor Coincoin

  5. 0

    Todos los demás se han clavado este (parametrizar!) pero sólo para tocar en un par de puntos aquí:

    • Es esta una solución viable para la WAITFOR ataque?
    • Hace es defenderse de otros similares vulnerabilidades?

    No, no. El WAITFOR truco es muy probable que sólo se utiliza para ‘oler’ de la vulnerabilidad; una vez que hayas encontrado vulnerables de la página, hay mucho más que se puede hacer sin DDL o (la no-SELECCIONAR partes de) DML. Por ejemplo, piense acerca de si se aprobó la siguiente como apellido

    ' UNION ALL SELECT username, password FROM adminusers WHERE 'A'='A

    Incluso después de agregar la Y 1 = 1, usted todavía está regado. En la mayoría de las bases de datos, hay un montón de cosas maliciosas que se puede hacer con sólo SELECCIONAR el acceso…

    OriginalEl autor Cowan

  6. -4

    Cómo seguir xkcd y desinfectar la entrada. Usted puede comprobar para palabras reservadas en general y para WAITFOR en particular.

    Por favor, no. No intente desinfectar con algunos de hojaldre lista negra del sistema. Si usted tiene alguna misteriosa pero intensa aversión a las declaraciones preparadas, a continuación, de escape las cadenas.
    Yo no -1 usted, pero podría parecer, que la primera frase de su respuesta podría justificar un +1 (ya que menciona xkcd), pero luego de llegar a la segunda frase. Y ahí es donde todo se cae a pedazos.
    La prohibición de palabras clave reservadas es una estrategia sólo la TSA puede permitirse el lujo de gastar miles de millones en y salirse con la suya.
    Ha, estaba cegado por la autoridad de xkcd 🙂 el Uso de declaraciones preparadas en el lugar es, obviamente, el camino a seguir.

    OriginalEl autor David Soroko

Dejar respuesta

Please enter your comment!
Please enter your name here