(Informado previamente a través de canales de seguridad, fue rechazado, ahora se realiza divulgación pública siguiendo un proceso de divulgación responsable)
Resumen / Solicitud
Como usuario, quiero que las imágenes enlazadas publicadas en el chat sean cacheadas por el servidor y solo entonces se me muestren para proteger mi IP de un servidor de alojamiento de imágenes de terceros malintencionado. ¡Aún quiero ver la imagen cacheada/proxy, sin embargo!
Discourse ya tiene configuraciones para esto, pero no se aplican correctamente al chat. Tener ambas configuraciones de enlace relevantes (abajo) habilitadas debería funcionar igual que en el foro. Es decir: la imagen alojada por terceros se descarga en el servidor y solo entonces se muestra al usuario.
Antecedentes / Impacto
En los viejos tiempos de los foros de Internet, era muy popular permitir a los usuarios publicar incrustaciones de imágenes “enlazando” a servidores de terceros que alojaban las imágenes.
Si bien esto era bastante común en foros antiguos, a medida que Internet avanzó, aprendimos que era una mala práctica. Casi todas las plataformas de redes sociales evolucionaron para evitar esto. Parte de la razón fue evitar problemas con imágenes rotas/perdidas, o sobrecargar servidores pequeños, pero también hay una consideración de seguridad muy importante:
Un usuario que publica una imagen de un servidor externo la descarga de ese servidor enlazado. Esto permite que un servidor malintencionado de terceros registre la IP del usuario. Esto es bastante problemático, ya que si el servidor es operado por un usuario malintencionado, ahora conoce la IP del otro usuario. (Imagina un caso en el que un usuario malintencionado te envía un mensaje para descubrir tu IP de casa)
Una IP filtrada puede ser utilizada por una persona malintencionada para determinar la verdadera identidad del usuario o para escanear su router doméstico / PC en busca de vulnerabilidades, etc. Incluso podrías ser capaz de hacer un XSS con él en otro sitio si ese otro sitio tiene alguna vulnerabilidad XSS.
Es por eso que prácticamente todas las principales redes sociales (Twitter, Discord, Facebook, etc.) ya no realizan enlaces de imágenes por razones de seguridad. Cada imagen de terceros ahora se cachea en el servidor en lugar de que el usuario la obtenga directamente.
Configuraciones Relevantes de Discourse
Discourse proporciona dos configuraciones relevantes:
Bloquear medios enlazados reemplazará las imágenes enlazadas con un enlace de texto en su lugar.
Descargar imágenes remotas a local convertirá las imágenes enlazadas a imágenes almacenadas localmente.
Comportamiento de la Configuración en el Foro
Con ambas configuraciones habilitadas, el foro parece funcionar como se esperaba en mis pruebas limitadas. Las imágenes externas se convierten en imágenes locales antes de que se muestren a otros usuarios, protegiendo la IP del usuario. No he intentado ataques de temporización exhaustivos para verificar el comportamiento, pero al menos en mis pruebas limitadas funcionó correctamente.
(Esto es lo que esperaría para cualquier plataforma social moderna, similar al comportamiento en Twitter/Discord/Facebook, etc.)
Comportamiento de la Configuración en el Chat
En el chat, no pude obtener un comportamiento similar. Ninguna combinación de configuraciones produce resultados satisfactorios:
Tener ambas configuraciones habilitadas convierte la imagen remota en solo un enlace. Sin embargo, hay una ventana de tiempo muy corta en la que la imagen aún se muestra al otro usuario y, por lo tanto, realiza una solicitud web, exponiendo la IP del usuario al otro usuario. Este es básicamente el peor resultado, ya que la IP del usuario está expuesta y ni siquiera puedes ver la imagen.
Tener Bloquear medios enlazados deshabilitado y Descargar imágenes remotas a local habilitado solo realiza un enlace; no pareció descargar realmente la imagen remota. No es una vulnerabilidad, pero parece un error.
Tener Bloquear medios enlazados habilitado y Descargar imágenes remotas a local deshabilitado tiene el mismo comportamiento que tener ambos habilitados. Se muestra como un enlace en lugar de una imagen, pero la imagen a veces es extraída por el cliente remoto, exponiendo la IP. (Encontré que a veces, la primera vez que se enviaba la imagen, la bloqueaba, pero la segunda vez, brevemente, no lo hacía, o ocurrían otros problemas probablemente relacionados con el tiempo con frecuencia).
(Re-probado en una copia de desarrollo de git hoy: 3.5.0.beta8-dev (2c0635ee4c))
Divulgación / Respuesta
Informé esto previamente (en 2024) por correo electrónico y HackerOne, pero me dijeron que no era un problema de seguridad y el informe de seguridad (2844784) fue rechazado, desafortunadamente. Aquí estaba la declaración relevante:
Gracias por tu informe. Después de una cuidadosa revisión, lo cerramos ya que el comportamiento descrito es una funcionalidad web estándar en lugar de una vulnerabilidad de seguridad.
Cuando un navegador carga cualquier recurso externo (imágenes, scripts, etc.), necesariamente realiza una solicitud al servidor de alojamiento. Este servidor verá naturalmente la dirección IP solicitante; esto es fundamental para cómo funciona Internet y no se considera una vulnerabilidad de seguridad por sí sola. Si bien las direcciones IP pueden considerarse datos personales en algunos contextos, su exposición a través de solicitudes web estándar es un comportamiento esperado que los usuarios aceptan implícitamente al navegar por Internet.
La protección de enlaces en Discourse está diseñada para prevenir el uso no autorizado de contenido alojado, no para ocultar las direcciones IP de los usuarios de servidores externos.
Este puede ser bien el caso de uso previsto de la función de bloqueo de enlaces, pero creo que no abordar esto pone en riesgo a los usuarios del plugin de chat, especialmente en comunidades más bulliciosas que pueden tener usuarios que intenten encontrar la IP de casa de un enemigo y hacer doxxing/DDOS.
También me opongo a la idea de que los usuarios consientan implícitamente el acceso a URL de enlaces no confiables en un sitio de foro confiable en la era moderna. No comentaré sobre las implicaciones de GDPR/etc, ya que no las conozco, pero solo desde una expectativa básica de privacidad, esto no se espera excepto en foros muy antiguos. Definitivamente no en los modernos.
Informé de mi intención de publicar públicamente en este foro sobre el problema el 22 de noviembre de 2024 y no he recibido respuesta desde entonces.
Estoy publicando aquí para que otros administradores de Discourse estén al tanto y, con suerte, animen al equipo de ingeniería a mejorar la protección de enlaces. Como ha pasado mucho tiempo y no ha habido mejoras, publico de buena fe con la esperanza de que la concienciación y quizás el aliento de la comunidad sobre la importancia del problema traigan mejoras.
Gracias por leer 