it-swarm-es.com

Riesgos de seguridad de buscar URL proporcionadas por el usuario

Estamos considerando agregar la siguiente característica a nuestra aplicación web (una base de datos de productos en línea, si es importante):

  • En lugar de cargar una imagen, el usuario puede proporcionar la URL (autohospedada) de una imagen. Almacenamos la URL en lugar de la imagen.

Hasta aquí todo bien. Sin embargo, a veces nuestra aplicación web tendrá que recuperar la imagen de la URL (externa, suministrada por el usuario) para hacer algo con ella (por ejemplo, para incluya la imagen en una PDF hoja de datos del producto).

Esto me preocupa, porque significa que nuestro servidor web enviará solicitudes HTTP a las URL proporcionadas por el usuario. Inmediatamente puedo pensar en muchas cosas malas que se pueden hacer con esto (por ejemplo, ingresando http://192.168.1.1/... como URL y probando algunas vulnerabilidades comunes de la interfaz web del enrutador). Eso parece similar a falsificación de solicitud entre sitios , solo que no es el servidor web engañando al usuario para que envíe una solicitud web, es el usuario engañando al servidor web.

Seguramente, no soy el primero en enfrentar este problema. Por lo tanto, mis preguntas:

  • ¿Este vector de ataque tiene un nombre? (Para que pueda hacer más investigación ...)
  • ¿Hay otros riesgos asociados con la obtención de URL proporcionadas por el usuario que debo tener en cuenta?
  • ¿Existen algunas técnicas de mejores prácticas bien establecidas para mitigar esos riesgos?
62
Heinzi

Esta vulnerabilidad en particular tiene un nombre. Se llama falsificación de solicitudes del lado del servidor (SSRF). SSRF es cuando un usuario puede hacer que una aplicación del lado del servidor recupere recursos que no fueron intencionados por el desarrollador de la aplicación, como otras páginas web en una red interna, otros servicios que solo están disponibles cuando se accede desde loopback (otros servicios web y API, a veces base de datos servidores) e incluso archivos en el servidor (file:///etc/passwd). Consulte Biblia SSRF y PayloadsAllTheThings para ver ejemplos de cómo se puede abusar de él. Dado que es una etiqueta de imagen, la mayoría de las cosas probablemente no se mostrarán, pero aún es un problema que solucionar.

¿Qué hacer al respecto? Puede hacer referencia a OWASP SSRF Cheat Sheet . Su situación coincide con el segundo caso, aunque no podrá realizar todas las mitigaciones, como cambiar las solicitudes a POST o agregar un token único. La orientación se reduce a:

  1. Protocolos permitidos en la lista blanca: Permitir HTTP y HTTPS, no permitir todo lo demás (por ejemplo, una expresión regular como ^https?://).
  2. Verifique que el nombre de host proporcionado sea público : muchos idiomas vienen con una biblioteca de direcciones IP; compruebe si el nombre de host de destino se resuelve en una dirección IPv4 o IPv6 no privada y no reservada *.
  3. Mi propia adición, reglas de firewall personalizadas: El usuario del sistema que ejecuta la aplicación web podría estar sujeto a reglas de firewall restrictivas que bloquean todas las solicitudes de red internas y servicios locales. . Esto es posible en Linux usando iptables/nftables. O contenedorice/separe esta parte de la aplicación y bloquéela.

Quizás también podría validar el tipo MIME del archivo en el momento de la recuperación para asegurarse de que sea una imagen. Además, no acepte redireccionamientos al recuperar la imagen, ni realice la misma validación si lo hace. Un servidor web malicioso podría enviar una respuesta 3xx que lo redirige a un recurso interno.

Además, mencionó que está generando archivos PDF a partir de los datos ingresados ​​por el usuario. La URL de su imagen a un lado, PDF generadores han sido históricamente un caldo de cultivo para las vulnerabilidades XXE (inyección de entidad externa XML) y SSRF. Por lo tanto, incluso si corrige la URL personalizada, asegúrese de que su PDF evita estos problemas, o realice la validación usted mismo. Una charla DEFCON describe el problema ( descarga de PDF ).

* Como se mencionó en los comentarios, las respuestas DNS pueden contener múltiples resultados, y las respuestas pueden cambiar entre solicitudes, causando un problema de tiempo de uso (TOCTOU). Para mitigar, resolver y validar una vez, y usar esa dirección IP validada originalmente para realizar la solicitud, adjunte el encabezado del Host para permitir que se llegue al Host virtual correcto.

69
multithr3at3d

Almacenamos la URL en lugar de la imagen.

Además, esto agregará información y riesgos de privacidad. Déjame mostrarte con una demostración visual.

Si intenta cargar cualquier imagen en StackExchange, notará que la imagen es alojada por imgur.com. El servidor SE recupera las imágenes y carga una copia en su servidor privado.

Usaré un meme popular e inocente para el experimento. Comencemos con la siguiente URL para nuestro programa: https://i.imgflip.com/2fv13j.jpg. Tenga en cuenta que tengo que usar un enlace profundo para que funcione esta demostración.

Quiero adjuntarlo a esta publicación usando la herramienta de carga StackExchange. Exactamente como el escenario en la pregunta.

A random image from the internet

???? ¡Aquí está nuestra imagen recién subida!

Vamos a profundizar e investigar más. Observe que la imagen ahora se obtiene de imgur.com en lugar de de imgflip.com. Tenga paciencia conmigo si las dos URL tienen nombres similares. Al abrir Herramientas para desarrolladores, puede ver hacia dónde apunta la imagen

A screenshot from Developer tools

Preocupaciones sobre la privacidad

Cuando vincula cualquier recurso en línea http (s): //, su navegador iniciará una conexión a ese servidor, enviando mucha información. En un sitio web de alto tráfico, el propietario del sitio web obtiene mucha información sobre las direcciones IP de las personas que visitan esta página de Security SE, junto con (si está habilitado) enlaces de referencia y cookies de terceros . Teniendo en cuenta que las cookies de terceros están habilitadas de forma predeterminada, esto puede filtrar la identidad del usuario si se abusa de la manera correcta.

Al ¡poseer la imagen que quiero subir a una publicación, StackExchange impide que imgflip.com sepa quién está mostrando su imagen.

Y, como veremos en la segunda parte, para cambiarlo en el futuro.

Riesgo de engaño.

Tenga en cuenta que no importa su esfuerzo para implementar un sitio web simple static " Front-page-ish ", cualquier URL a un recurso remoto siempre es interpretado por el servidor, en cada solicitud. Si bien puede terminar con .jpg es probable que el servidor esté usando un lenguaje de secuencias de comandos para interpretar la solicitud y, al final, elegir qué contenido servir .

Ahora que ha perfilado a sus visitantes, tiene el poder de elegir qué contenido mostrarles en vivo . Considere el caso de Uber-Greyball como un ejemplo de engaño en vivo. La popular aplicación de citas Tinder utiliza una tecnología similar de prohibición suave o lista gris

Desconocido para las [...] autoridades, algunos de los autos digitales que vieron en la aplicación no representaban vehículos reales. Y los conductores de Uber que pudieron llamar también cancelaron rápidamente. Eso se debió a que Uber había etiquetado [... al Sr. Oficial de Policía ...] - esencialmente Greyballing como funcionarios de la ciudad - en base a los datos recopilados de la aplicación y de otras maneras.

Como ejemplo, el servidor puede implementar tal lógica: decidir dónde servir un meme inocuo o un contenido ¡indeseable, p. publicidad política, basada en la solicitud del usuario (recuerda a algunos ¿Cambridge Analytic-thing? ). Sin embargo, la URL nunca cambia.

La ventaja declarada de CA es tener suficientes puntos de datos en cada estadounidense para crear amplios perfiles de personalidad, que sus clientes pueden aprovechar para la "orientación psicográfica" de los anuncios.

request for https://Host.com/images/img1.png
if (request comes from any of
      StackExchange moderator or
      Automated content filter or
      Government enforcer or
      Anything you can imagine)
{
    decide to serve innocuous content
}
else if (request comes from a user you want to decept)
{
    decide to serve a targeted advertising or deceptive content somehow
}

Mire esta imagen para ver qué puede pasar con el filtrado en tiempo real. En la misma URL, diferentes usuarios ven contenido diferente. Gracias a Lord Buckethead por mantenerme políticamente neutral.

Different content served from the same URL

En la misma URL, ahora podemos servir contenido diferente con respecto a who lo está solicitando.

Por estas razones, debe considerar la obtención del recurso remoto para tomar una instantánea permanente del mismo, con respecto a las limitaciones de ancho de banda y espacio en disco.

No discutiré aquí sobre 1) retener etiquetas EXIF ​​y 2) volver a codificar la imagen con su propio códec para evitar nuevos ataques de carga útil

30

En lugar de cargar una imagen, el usuario puede proporcionar la URL (autohospedada) de una imagen. Almacenamos la URL en lugar de la imagen.

¿Quieres decir este tipo de archivos JPEG ?

Es una mala idea En primer lugar, deberá verificar la validez de la imagen cada vez que la use. Eso lleva tiempo. Supongo que la base de datos es utilizada por otros usuarios, y usted no tendrá control alguno sobre qué tipo de JPEG maliciosos recibe el usuario de la base de datos. Le preocupa que obtenga una imagen maliciosa, pero está dispuesto a permitir que otras personas que usan su base de datos solo obtengan una imagen maliciosa.

Entonces, no tan lejos tan bueno.

Por sí mismo, trate la imagen como trataría cualquier entrada de una fuente no confiable. Eso significa: verificar que la imagen sea correcta. Es posible que desee convertirlo a algún formato estándar; es posible que desee volver a codificar para estar seguro.

28
Ljm Dullaart