Probar mi propia carga de archivos del servidor

1

Recientemente creé mi propio servidor IIS (configurado en la versión 7.5) y estuve revisando para asegurarme de que mi webdav no sea vulnerable. Mis usuarios necesitan cargar archivos en sus cuentas individuales y pueden acceder a ellos a través de un enlace directo al servidor, y en este momento he deshabilitado todos los scripts del lado del servidor que no se han cargado (php (php3, php4, php5, etc.) perl, net, asp, htaccess files, etc.) pero sigo permitiendo que se carguen imágenes, archivos exe y html.

Solo deshabilité las extensiones para que no se cargaran, pero hasta ahora no he encontrado nada vulnerable al hacer esto. ¿Cubre esto posibles ataques de carga de archivos?

    
pregunta user2852841 13.10.2013 - 18:34
fuente

3 respuestas

2

¿Estás usando PHP? Hay un par de cosas a tener en cuenta. Escribí este artículo a principios de este año que trata sobre la carga de archivos y otros temas. Creative Commons, así que siéntase libre de guardar una copia, modificarla y compartirla como desee: enlace

"Cifre sus archivos, guárdelos en un nombre de archivo aleatorio en un directorio específico que no sea webroot, y use una base de datos para realizar un seguimiento de sus metadatos (tipo, nombre de archivo, tamaño). Use un script para enviarlos desde el sistema de archivos. y use las llamadas de cabecera () y reescriba las directivas para engañar a los navegadores y tratarlas como imágenes. Almacene en caché para evitar el agotamiento de los recursos ".

No necesariamente necesitas cifrarlos; gzip comprimiéndolos o codificados en base64 evitará la ejecución en caso de que logren acceder directamente al archivo. Recomiendo abstraer el nombre de archivo que la gente ve lejos de lo que realmente está presente en el sistema de archivos . Si bien la gente puede objetar esto como una forma de "seguridad a través de la oscuridad", pero si almacena todo como un archivo .txt, nada se ejecutará al acceder a un archivo cargado.

Una cosa muy importante: No confíe en la extensión de archivo o en el valor $ _FILES ['abc'] ['type'] proporcionado por el usuario. Se pueden falsificar.

    
respondido por el Scott 13.10.2013 - 18:42
fuente
1

Algunos puntos básicos que tengo en cuenta en esta situación son:

  • defina un archivo .htaccess y especifique qué formatos están permitidos en él. No coloque el archivo .htaccess en el mismo directorio que los archivos cargados.
  • Especifique en el archivo .htaccess, las extensiones que están permitidas. Use alguna expresión regular para prevenir el ataque de doble extensión.

  • Suba los archivos en otro lugar que no sean los servidores raíz.

  • No permita sobrescribir los archivos existentes en el directorio de carga.
  • Crea una lista de tipos mime permitidos.
  • No confíe solo en la validación del lado del cliente, ya que no es suficiente. Idealmente, uno debería tener implementada la validación del lado del servidor y del lado del cliente.

P.S: Los he tomado de un par de sitios y no tengo sus enlaces ahora. Estos consejos estaban en mis notas personales. Lo siento por no dar el debido crédito.

    
respondido por el Jor-el 13.10.2013 - 18:54
fuente
0

¿Se cargan a sus propios dominios separados? Si no, su sistema puede ser vulnerable a XSS.

También asegúrese de haber abordado todos los puntos planteados aquí: enlace

    
respondido por el SilverlightFox 14.10.2013 - 11:25
fuente

Lea otras preguntas en las etiquetas