Los usuarios suben imágenes de perfil; el servidor las almacena en la raíz web y las vuelve a servir. ¿Cuál es el riesgo?
Respuesta breve
Si un atacante puede subir un archivo ejecutable del lado del servidor (o HTML/SVG) a un directorio servido, puede lograr ejecución remota de código o XSS almacenado. Valide el tipo de contenido real, almacene los archivos fuera de la raíz web o en un almacén no ejecutable, aleatorice los nombres y sírvalos de modo que no puedan ejecutarse ni interpretarse como marcado. Las cargas de página más lentas y el uso de disco son problemas operativos, no el riesgo de seguridad explotado aquí.
«Solo son imágenes de perfil» es la suposición que convierte un formulario de subida en una shell remota. En cuanto los usuarios pueden escribir un archivo en un directorio que el servidor web va a servir y ejecutar, la función de subida se convierte en un canal de entrega de código.
Por qué es peligroso
Si el servidor ejecuta PHP, JSP, ASPX, etc., un atacante sube avatar.php en lugar de un PNG y luego lo solicita — el servidor lo ejecuta, otorgando ejecución remota de código (RCE) y un punto de apoyo en el host. Incluso sin un motor de scripts, un archivo HTML o SVG subido y servido desde su origen ejecuta JavaScript en el navegador de sus usuarios, dando XSS almacenado y robo de sesión. Los atacantes eluden las comprobaciones ingenuas con dobles extensiones (shell.php.png), bytes nulos, cabeceras Content-Type falsas o archivos políglotas cuyos magic bytes parecen una imagen pero cuyo final es código activo.
La solución correcta
Superponga las defensas:
- Valide el contenido real, no solo la extensión o el
Content-Typeproporcionado por el cliente — compruebe los magic bytes y, idealmente, recodifique la imagen para neutralizar cualquier carga incrustada. - Almacene las subidas fuera de la raíz web o en almacenamiento de objetos / un origen separado que no pueda ejecutar código y que sirva con un
Content-Typebenigno másContent-Disposition: attachment. - Aleatorice los nombres de archivo para que los atacantes no puedan predecir ni sobrescribir rutas, y elimine el nombre original.
- Restrinja el tamaño y el tipo, y ejecute antivirus/escaneo cuando proceda.
Por qué las demás respuestas son incorrectas
«Sin riesgo — solo son imágenes» es justo el punto ciego que despliega la vulnerabilidad; el tipo declarado del archivo lo controla el atacante. «Cargas más lentas» y «uso excesivo de disco» son preocupaciones operativas reales, pero tratan de capacidad, no de compromiso — un entrevistador que pregunta «¿cuál es el riesgo?» espera que nombre el RCE / XSS almacenado y los controles de almacenamiento y validación que impiden que un archivo subido llegue a ejecutarse o a interpretarse como marcado.
Posibles preguntas de seguimiento
- ¿Por qué comprobar la extensión o la cabecera Content-Type no es suficiente por sí solo?
- ¿Cómo puede un archivo SVG o HTML subido llevar a XSS almacenado incluso sin ejecución de código?
- ¿Cómo servir las subidas de usuarios desde un origen separado y por qué ayuda?