inyección SQL ¿Hay casos en que una URL vulnerable no contenga el símbolo 'igual' (=)

7

Tengo una pregunta con la que espero que puedas ayudar?

Estoy buscando filtrar / grep una lista muy larga de url spidered desde mi sitio para obtener solo los url que podrían ser vulnerables a la inyección de SQL.

Mi pregunta: ¿Es cierto que cualquier URL que pueda ser vulnerable a la inyección de SQL siempre contiene un símbolo 'igual a' (=) en la URL?

Por lo tanto, si fuera a grep para todas las direcciones URL que contienen un símbolo '=' en la dirección URL, ¿omitiría cualquier otra dirección URL que no contenga un símbolo '=' que aún podría ser vulnerable?

Por ejemplo , todos contienen un símbolo '=' y podrían ser vulnerables a la inyección de SQL.

http://[website]/index.php?itemid=10
http://www.[yoursite].org/site/page.asp?CID=72&DID=
http://www.[mysite].com/site/page.asp?=

¿Hay casos en los que las direcciones URL no contengan un '=' y aún sean vulnerables a la inyección de SQL?

-------EDIT-------

SOLO estoy interesado en alterar / inyectar la URL en la barra de URL de mi navegador para ver si alguna URL en mi lista es potencialmente vulnerable a la inyección de SQL (es decir, no estoy interesada en inyectar formularios o solicitudes POST, etc.). p>

Tengo una lista de URLS en un archivo txt

FILE.txt

http://www.[site].com/index.php?itemid=10
http://www.[site].com/
http://www.[site].com/site/page.asp?CID=72&DID=
http://www.[site].com/animals/pictures
http://www.[site].com/pictures
http://www.[site].com/index.php?itemid=7
http://www.[site].com/faq

Quiero filtrar / grep este archivo txt para obtener solo las URLS que contienen un símbolo '=' como se muestra a continuación:

FILTEREDFILE.txt

http://www.[site].com/index.php?itemid=10
http://www.[site].com/site/page.asp?CID=72&DID=
http://www.[site].com/index.php?itemid=7
http://www.[site].com/site/page.asp?CID=72&DID=

Usando estos URLS en FILTEREDFILE.txt Luego usaré un bucle foreach para agregar un apóstrofe al final de cada uno para ver si es vulnerable a la inyección de SQL mirando el Longitudes de contenido de respuesta para ver si hay un cambio / diferencia.

Sé que incluso en la URL y no contiene un '=' que todavía puede haber vulnerabilidades de inyección de SQL en los formularios y solicitudes POST y así sucesivamente, pero no estoy interesado en esas en este momento.

IMPORTANT:

Solo me interesan las vulnerabilidades que pueden determinarse cambiando / alterando la URL en sí misma (es decir, agregando un apóstrofe al final de http: // www. [sitio] .com / índice .php? itemid = 7 y así sucesivamente).

Lo que quiero saber es si extrapolaré el archivo txt para URLS que contengan un símbolo '=' , me perderé cualquier URLS que aún pueda ser vulnerable y que no contenga un ' = 'símbolo. (excluyendo formularios, POSTS, reescrituras de URL, solo manipulando la URL en la barra de URL)

Espero que esto explique mejor mi pregunta,

gracias por tu ayuda

    
pregunta perl-user 20.02.2013 - 10:52
fuente

4 respuestas

12

Las inyecciones de SQL se pueden realizar en cualquier parte de la solicitud. Cualquier parámetro de la solicitud HTTP puede contener datos SQL que pueden engañar a la aplicación para que la inyecte en la base de datos.

Por ejemplo, Amazon tiene los ID de producto en la URL enlace Esto se llama reescritura de URL y el servidor web extrae el ID del producto de la URL y lo utiliza para consultar la base de datos.

Sin tener disponible el código fuente, no hay forma de saber qué consultas SQL se están realizando. Una aplicación web puede realizar un DNS inverso en la dirección IP de conexión e insertar ese nombre en la base de datos. Pero la IP puede resolverse en una cadena que realiza una inyección de SQL.

Estas son algunas de las formas de obtener variables de la URL en la aplicación web:

  • Wikipedia usa los dos puntos (:). Ejemplo: enlace
  • las aplicaciones JavaScript pueden usar fragmentos (#) como entrada. ej .: enlace
  • Tilde (~) fue popular una vez. ej: enlace
  • Puede encontrar enlaces de controladores de protocolo como data: o javascript: que pueden pasar datos indirectamente a la aplicación web. ej: javascript:addtocart(5)

Al analizar sus enlaces, recuerde que los caracteres pueden estar codificados en URL.

    
respondido por el Cristian Dobre 20.02.2013 - 10:57
fuente
1

Es posible que no contenga el signo igual, incluso si no se ha reescrito la URL, pero dependerá de qué tan mal esté codificado el sitio web.

Cualquier parte de la url web, que dará como resultado una consulta de SQL, podría usarse para realizar una inyección de SQL si no se la desinfecta correctamente.

Las variables de obtención podrían pasarse sin valor, solo la definición.

Considera este ejemplo:

URL: http://site.com/user.php?user-1234

Código:

foreach ($_GET as $k => $v) {
    $k2 = explode('-', $k);
    if ($k2[0]='user') $res=$k2[1];
}
//do sql query with $res
    
respondido por el sharp12345 20.02.2013 - 16:08
fuente
1

Toda la entrada es vulnerable a la inyección de SQL, por lo que siempre debe filtrar y verificar en el lado del servidor. No se preocupe por el origen, solo en el momento en que esté utilizando una variable del usuario, por leer un archivo, más o menos en el momento en que no tenga el valor codificado, debe hacer el escape y la verificación adecuados.

Si aún no está familiarizado con OWASP, le sugiero que comience con su guía sobre Inyección de SQL .

No confiaría en la cadena igual como detector, puede que obtengas una inyección SQL que cambia la funcionalidad o dispara un cheque booleano con un simple ataque de inyección de comentarios.

También, como se indica en las otras respuestas, si filtra por cadenas de consulta, pierde las páginas que procesan los datos de formularios transmitidos mediante el método POST . Por ejemplo, si tiene la url que procesa los resultados de un envío de formulario, es posible que no tenga ningún parámetro de obtención, pero aún será posible la inyección de SQL cuando se procesen los valores de POST . Leí su publicación completa, pero no estoy seguro de por qué no querría verificar todos los formularios de entrada si está haciendo el esfuerzo de probar su aplicación. Es mejor ejecutar algunas herramientas automatizadas como nikto, escáner de burp , o AppScan si tiene los fondos.

Parece que estás haciendo un gran esfuerzo para cubrir solo una parte del problema. Además, si tiene el código fuente, comenzaría allí si fuera un programador en lugar de identificar las páginas, porque podría haber varias páginas que llamen a la misma función.

    
respondido por el Eric G 23.02.2013 - 02:14
fuente
0

Respuesta corta no, no puede asumir que solo las URL con un = en ellas son posibles vectores para la inyección de SQL.

El problema con esta suposición es que ignora el uso de los controladores de contenido y los marcos web que usan la información de la ruta url para determinar a qué controlador / procedimiento se llama y cómo manejar la información de la ruta. Considere muchos servicios basados en REST que utilizan este enfoque, así como muchos marcos web populares.

Podría tener una URL como

enlace

donde se llama al manejador y se pasa aargement1, aargement2 y aargement3. Dependiendo de cómo se implementa el manejador y de lo que hace, puede proporcionar fácilmente un vector para la inyección de SQL.

    
respondido por el Tim X 23.02.2013 - 00:04
fuente

Lea otras preguntas en las etiquetas