¿Es una vulnerabilidad permitir la solicitud de rizos sin filtros desde un sitio web?

Navega tus respuestas
13

Recientemente estuve en un sitio web que proporcionaba alguna característica sin sentido:

  • Introduce una URL
  • presiona enter
  • Se muestra la fuente HTML de una URL dada

Básicamente recuperó una URL y simplemente volcó el contenido de la misma. Podría ser XML, txt, HTML, cualquier ruta accesible a través de curl.

Ahora me parece que esto debería ser bastante peligroso, ¿verdad?

No tengo Linux a mano y no pude encontrar este sitio, pero una página de PHP rápidamente pirateada en mi máquina con Windows consumió felizmente la URL: 

file://D:/something/index.html

y me lo presentó. ¿Esto no permitiría básicamente que un atacante deambulara por la máquina en la que se ejecuta el script? ¿Esta URL 

file:///etc/passwd

¿trabajar en linux?

¿Hay otros problemas obvios con eso?

¿Hacerse pasar por otra persona que accede a otros recursos a través de esquemas como POP3, LDAP, smb?

Mientras escribía esto, me pregunté si los esquemas de listas blancas para HTTP [S] y tal vez FTP solucionaría esos problemas.

Todavía podría suplantar a un visitante en un sitio a través de esta página, pero no tengo conocimiento de ningún problema, excepto visitar contenido ilegal o, probablemente, eludir cosas como la censura.

    
pregunta Samuel 01.08.2015 - 16:05
fuente

2 respuestas

13

Si la entrada no se filtra con cuidado, es una vulnerabilidad llamada falsificación de solicitud del lado del servidor (SSRF) .

Incluso hay un número de enumeración de debilidad común y una página para ello. enlace

  

Al proporcionar direcciones URL a hosts o puertos inesperados, los atacantes pueden hacerlo   Aparece que el servidor está enviando la solicitud, posiblemente evitando   controles de acceso tales como cortafuegos que impiden a los atacantes   Accediendo directamente a las URL. El servidor puede ser utilizado como un proxy para   realizar escaneo de puertos de hosts en redes internas, usar otras URL   como el que puede acceder a documentos en el sistema (usando file: //), o   use otros protocolos como gopher: // o tftp: //, que pueden proporcionar   Mayor control sobre el contenido de las solicitudes.

Al explotar esta vulnerabilidad, un atacante puede:

  • Escanee hosts desde la red interna del servidor que normalmente no está accesible
  • Enumerar y atacar los servicios que se ejecutan en estos hosts
  • Aproveche las relaciones de confianza que podría tener el servidor vulnerable
  • Proxy de tráfico HTTP a través del servidor vulnerable que enmascarará la fuente del tráfico
La compatibilidad con

Sin filtrar cURL es incluso peor que una vulnerabilidad SSRF normal porque cURL admite muchos esquemas de URL además de HTTP y HTTPS. Ejecute #curl-config --protocols para ver qué es compatible.

  • Puede acceder a los archivos locales con el esquema de URL file:// ( curl file:///etc/passwd funciona en Linux)
  • Es posible usar el esquema de URL dict:// para realizar solicitudes a cualquier host en cualquier puerto y enviar datos personalizados. La URL dict://host:port/command hará que el servidor se conecte a un host y envíe la cadena command al puerto especificado.
  • Accede a diferentes servicios:
    • ldap://
    • ftp://
    • scp://
    • smb://
    • telnet://
    • imap://
    • pop3://
    • smtp://
    • rtsp://
    • tftp://
respondido por el Cristian Dobre 01.08.2015 - 21:42
fuente
9

Bueno, dependiendo de cómo hayan implementado esta característica, podría ser bastante peligroso. Además de los riesgos que ha mencionado, también existe la posibilidad de que el sistema recupere las URL no públicas. Por ejemplo, recuperar enlace recuperaría localhost.

Esto puede ser un riesgo, ya que los paneles de administración generalmente se implementan a través de HTTP (s) en estos días y es probable que sean accesibles al servidor local y no a otras IPs aleatorias.

Ahora, por supuesto, puede descubrir que el sitio está filtrando correctamente todos estos ataques, ya que no sería evidente a menos que los pruebe (lo que, por supuesto, podría ser legalmente dudoso según su jurisdicción ...)

    
respondido por el Rоry McCune 01.08.2015 - 17:52
fuente

Lea otras preguntas en las etiquetas

Desafío desafiante: el hashing de la contraseña del lado del cliente y la verificación de la contraseña del lado del servidor ¿Por qué es problemático el cifrado (o firma) de largas filas en correos electrónicos con PGP?