Inyección SQL Cómo inyectar URLS de limpieza / descanso

Navega tus respuestas
9

Tengo una pregunta con la que espero que puedas ayudarme?

URLs sucios: 

http://example.com/index.php?page=foo
http://example.com/products?category=2&pid=25
http://example.com/index.php?mod=profiles&id=193
http://example.com/kb/index.php?cat=8&id=41

Limpiar las URL (las URL equivalentes una vez que se hayan "limpiado"): 

http://example.com/foo
http://example.com/products/2/25
http://example.com/profiles/193
http://example.com/kb/8/41

Explicación de la URL limpia / no limpia aquí

Mi pregunta:

Como puede ver en los ejemplos de direcciones URL sucias y limpias, obviamente, difieren ligeramente.

Con las URLs sucias, sería posible probar una posible vulnerabilidad de inyección de SQL añadiendo un apóstrofe (') al final de la URL y así sucesivamente ...

por ejemplo, http://example.com/products?category=2&pid=25' y luego mirando las longitudes de respuesta que devuelve.

Soy consciente de que el uso de URL limpias / de descanso no lo hace menos vulnerable a la inyección de SQL y se utiliza principalmente para SEO, usabilidad, etc. (aunque también lo hace más difícil para SQL automatizado herramientas de inyección), pero ¿cómo se inyectaría estos tipos de url y hay un método particular, preferido / mejor para usar?

por ejemplo, ¿el siguiente trabajo para inyectar urls limpios (usando un apóstrofe)?

http://example.com/kb/8'/41

o

http://example.com/products/2'/25

o

http://example.com/services/legal/patents'

y así sucesivamente ... o hay un método preferido / mejor.

Su ayuda con esta pregunta sería muy apreciada, muchas gracias

    
pregunta perl-user 22.02.2013 - 11:02
fuente

3 respuestas

4

En mi opinión, el principal problema cuando un pentester se enfrenta a una aplicación web que usa URL limpias es identificar qué partes de la URL son recursos y qué partes son parámetros porque generalmente los parámetros son lo que probamos más profundamente.

En este caso, creo que la mejor opción es probar todas las partes de las URL asumiendo que todas las partes son parámetros: 

http://example.com/kb'/8/41
http://example.com/kb/8'/41
http://example.com/kb/8/41'

La marca de verificación es solo un ejemplo, el caso es que todas las partes (incluido kb que se supone que es un recurso pero también podría ser un parámetro).

Si hay una manera de diferenciar en los parámetros y recursos de prueba de caja negra, me gustaría saberlo.

    
respondido por el kinunt 22.02.2013 - 18:22
fuente
5

No existe una prueba de magia para probar la inyección de sql. Algunas aplicaciones pueden ser vulnerables al usar un enfoque determinado y otras al usar otro.

Existe la posibilidad de que enlace '/ 41 no funcione porque un IPS bloquea los apóstrofos, pero enlace mostraría el mismo resultado que enlace y esto le daría la información de que hay un problema allí.

Solo hacer pruebas con comillas es un poco mejor que no hacer ninguna prueba, pero no se puede etiquetar como una evaluación de seguridad. Dicho proceso implica una evaluación compleja de todos los puntos de entrada posibles en su aplicación (parámetros, cookies, encabezados, etc.) y otras pruebas más complejas.

Si tiene la posibilidad, la mejor solución es utilizar un enfoque de caja blanca y también revisar el código. De esta manera, podría ver claramente si un determinado parámetro está correctamente saneado o no.

    
respondido por el Dinu S 22.02.2013 - 13:50
fuente
3

Las URL limpias se pueden implementar de manera diferente y, por lo tanto, dependen del sistema que se use. Por ejemplo, con reglas de reescritura en el servidor web: 

url.rewrite-final = (
  "^/system/test/(.*)$" => "/index.php?q=system/test/$1",
  "^/([^.?]*)\?(.*)$" => "/index.php?q=$1&$2",
  "^/([^.?]*)$" => "/index.php?q=$1",
   "^/rss.xml" => "/index.php?q=rss.xml"
)

Como puede ver, estas expresiones regulares (.*) también coincidirán con ' o " y si el script php no maneja esta entrada correctamente, puede ser vulnerable a la inyección SQL.

Aquí hay otro ejemplo, donde las URL limpias se implementan en la aplicación Web en sí misma (en este caso con Python WebFramework django ): 

urlpatterns = patterns('',
    (r'^articles/2003/$', 'news.views.special_case_2003'),
    (r'^articles/(\d{4})/$', 'news.views.year_archive'),
    (r'^articles/(\d{4})/(\d{2})/$', 'news.views.month_archive'),
    (r'^articles/(\d{4})/(\d{2})/(\d+)/$', 'news.views.article_detail'),
)

Como puede ver aquí, el desarrollador usó expresiones como (\d{4}) que coinciden con 4 digets como 1234 , 2001 , 1995 , ... pero no 12 o 12345 - y por lo tanto también no 12' .

TL; DR Esto significa que puede inyectarlos como las URL no limpias , si el desarrollador no usó las expresiones adecuadas.

editar: no puedes saber qué parte de la URL limpia son valores y cuáles son las claves, por lo que debes identificarlos con una razón o simplemente probarlos también.

    
respondido por el samuirai 23.02.2013 - 12:51
fuente

Lea otras preguntas en las etiquetas

¿Cuáles son los beneficios e inconvenientes del elemento HTML5 Keygen? ¿Tendría sentido usar Bcrypt y PBKDF2 juntos?