¿Es seguro aceptar una carga de archivo sin ninguna extensión de archivo?

3

Actualmente, estoy trabajando en un sitio web que permite a los usuarios cargar archivos de datos para su procesamiento automatizado. Tanto por motivos de seguridad como de guía para el usuario, implementamos una lista blanca de extensión tanto del lado del cliente como del servidor para aceptar solo los sufijos de datos comunes como .txt y .csv, etc.

Ahora hemos descubierto que algunos archivos de datos que nos envían no tienen ninguna extensión de archivo.

Estos procesos no son ejecutados por los procesos después de la carga: se analizan en busca de patrones de texto. Por lo tanto, tener archivos no verificados en el servidor no presenta, en teoría, un gran riesgo de seguridad. Sin embargo, los datos que se procesan son datos personales cubiertos por la ley de protección de datos, por lo que una violación sería catastrófica.

¿Es seguro permitir a los usuarios cargar archivos sin extensiones en esta instancia? Y, como una pregunta más amplia, ¿es una buena práctica permitir que un sitio permita estos archivos?

    
pregunta Matt Thrower 05.01.2018 - 16:08
fuente

3 respuestas

1

La extensión en sí no debería importar. Sería bueno averiguar el tipo MIME para conocer el contenido en su lugar.

En cuanto a los riesgos de seguridad en términos de carga de archivos, consulte también enlace

    
respondido por el Gambaz 05.01.2018 - 16:53
fuente
1

Debería estar haciendo verificaciones del lado del servidor para asegurarse de que el contenido que está obteniendo sea el esperado. Probablemente desee revisar el contenido de los archivos para asegurarse de que esté restringido a los requisitos comerciales específicos. por ejemplo, si esto es para cargar un CSV de cumpleaños, no debería haber etiquetas <script> en el archivo.

Por lo general, no quieres que la gente almacene cosas aleatorias en tus servidores a menos que seas DropBox o un servicio así. En cuyo caso, debe tomar precauciones especiales, como almacenar los archivos en un servidor en su propio subdominio y limitar la ejecución y descarga remota, la exploración A / V, etc.

  

Estos procesos no son ejecutados por los procesos después de la carga: se analizan en busca de patrones de texto. Por lo tanto, tener archivos no verificados en el servidor no presenta, en teoría, un gran riesgo de seguridad. Sin embargo, los datos que se procesan son datos personales cubiertos por la ley de protección de datos, por lo que una violación sería catastrófica.

Si permite que se carguen archivos arbitrarios en su servidor, existen algunos riesgos:

  • Si es un script y su servidor está mal configurado, puede permitir que el archivo cargado se ejecute en el lado del servidor. por ejemplo, estás usando apache y suben un archivo PHP, pero tienes algo como DefaultType application/x-httpd-php o ForceType application/x-httpd-php en su configuración.
  • Los ataques de inclusión de archivos locales son posibles si puede obtener otro script o servicio para llamar a este archivo.
  • Si es un archivo JS, pueden cargar un archivo en su servidor y llamarlo de forma remota en sus ataques XSS.
  • Si se trata de un script de punto final (bash, PowerShell), se podría apuntar desde otro script para ser descargado por wget , curl , etc. y luego ejecutarse
respondido por el Eric G 05.01.2018 - 17:40
fuente
0

La adición de la extensión no solucionará el problema potencial de las vulnerabilidades del analizador de archivos, el usuario puede cambiar el nombre de un archivo con formato incorrecto con csv / txt sin problemas.

Debes anotar todos los riesgos potenciales y cerrarlos, por ejemplo.

  • Verifique el tipo de archivo, debería haber módulos para lidiar con esto
  • Use una herramienta para buscar posibles palabras clave de inyección en el CSV antes de realizar el análisis
  • Ir a la hoja de trucos de prevención de inyección SQL .
respondido por el mootmoot 05.01.2018 - 16:54
fuente

Lea otras preguntas en las etiquetas