Cómo diseñar una función de carga de archivos segura
En los últimos dos días, nuestro viejo amigo PDP dio un discurso sobre GIFAR en BlackHat 08. Como siempre, el material de PDP es básicamente obsceno, al igual que éste. El tema trata sobre cómo agrupar un archivo GIF o JPG con un archivo JAR y luego engañar al servidor haciéndole creer que es un archivo GIF o JPG, pero el resultado es un ejemplo de ejecución del JAR en la JVM del cliente.
También dio algunos ejemplos de engaño. Por ejemplo, en Office 2007, el archivo doc en realidad está en formato zip y contiene algo de xml. Luego empaquetó el archivo jar en el archivo zip y luego agregó el archivo. sufijo Cámbielo a doc para lograr el propósito del engaño.
Este es un problema del cliente, pero estoy pensando en otros problemas, como la carga segura.
Basándonos en experiencias pasadas, podemos diseñar las siguientes reglas de seguridad para la carga de archivos:
1. El directorio para la carga de archivos está configurado como no ejecutable
. 2. Determine el tipo de archivo
3. Establezca el nombre de dominio del servidor de archivos por separado
4. Reescriba el nombre del archivo, la ruta del archivo es impredecible
La primera regla es obvia, para reducir el riesgo de ejecutar scripts en lenguajes dinámicos. Si un webshell se carga con éxito pero no se puede ejecutar, aún puede desempeñar un papel en la defensa en profundidad.
Segundo punto, al juzgar los tipos de archivos, generalmente requerimos el uso de una lista blanca en lugar de una lista negra, porque la lista negra puede no estar completa y también puede causar algunos riesgos de omisión.
Por ejemplo, la versión anterior de FCKEditor tenía este problema antes. Solo controlaba la lista negra y finalmente fue omitida.
Apache tiene una función que analiza el sufijo del archivo después del primer "." como tipo de archivo. Por ejemplo, fvck.php.rar.rar.rar será analizado por Apache como fvck.php.
Recientemente leí el manual de PHP. En la documentación de instalación, hay una guía especial para este problema:
15. Dígale a Apache que analice ciertas extensiones como PHP. Por ejemplo, tengamos
, queremos evitar cargas y archivos creados
potencialmente peligrosos como exploit.php. ejecutándose como PHP. Usando este
ejemplo, podría analizar cualquier extensión como PHP simplemente agregándolas
. Agregaremos .phtml para demostrarlo.
lt;FilesMatch .php$gt;
Aplicación SetHandler/x-httpd-php
lt;/FilesMatchgt;
IIS6 también tiene esta A Una característica similar es que cuando el nombre de la carpeta es fvck.asp (fvck se puede reemplazar con cualquier valor), cualquier archivo en la carpeta se ejecutará como asp.
Parece que no se ha visto hasta ahora Hay indicios de que Microsoft está tratando esta característica como un error que hay que corregir.
Entonces, si no está familiarizado con las características de estos servidores web, puede pensar que la vulnerabilidad es tan mágica: claramente he hecho suficientes restricciones, ¿por qué sigo "haciendo flexiones"?
Al determinar el tipo de archivo, la mayoría de los programas utilizan el método de verificar el sufijo del archivo. El principal truco de piratería al que se debe prestar atención aquí es si algunas funciones de verificación terminarán en 0 bytes; ha aparecido una vulnerabilidad similar. en Dongwang antes. Cargar fvck.jpg00.asp puede omitir la verificación del tipo de archivo.
También he visto que solo verifique el encabezado del archivo. Esto también es fácil de engañar. Construya un encabezado de archivo gif legal y luego pegue el shell web detrás de él. Si el sufijo es legal, lo hará. todavía funciona Analizado por el navegador:
GIF89a ?
lt;? phpinfo();
El más avanzado es hacer más archivos. Verificaciones de formato, como verificar la longitud y el ancho de los píxeles en la imagen y luego comprimir la imagen. La imagen resultante básicamente se deformará y cualquier webshell se destruirá.
Al comprobar los formatos de archivos, generalmente se utilizan algunas clases que se han empaquetado en línea, lo que tiene ventajas a la hora de escanear formatos de archivos. Sin embargo, la eficiencia es obviamente una cuestión que debe tenerse en cuenta al comprobar archivos grandes, y es posible que muchos programadores no estén dispuestos a elegir este método por razones de eficiencia.
Pero hoy en día, a juzgar por el engorroso método de vincular archivos en PDP, todavía es muy necesario verificar el formato del archivo en detalle, porque el objetivo del atacante puede no solo ser el servidor, sino también el cliente. Si desea garantizar al cliente, el formato del archivo debe verificarse en detalle para que entre en la lista blanca.
El tercer punto es que configurar el nombre de dominio del servidor de archivos por separado también es un tipo de protección del cliente. Esto puede evitar muchos problemas entre dominios.
Si se produce XSS, es posible que el atacante deba romper las restricciones entre dominios para ampliar aún más los resultados. Por ejemplo, si se carga crossdomain.xml, puede causar problemas entre dominios en flash. Estos son riesgos reales.
El cuarto punto es reescribir el nombre del archivo y la ruta aleatoria del archivo. Esto es para ocultar el riesgo. Hoy en día, la mayoría de los programadores concienzudos lo diseñarán de esta manera. Esta también es una forma muy práctica y eficaz de minimizar el riesgo.
Cabe señalar que el algoritmo para construir un nombre de archivo o ruta aleatorios debe ser lo suficientemente "aleatorio", en lugar de tomar directamente un hash de un lugar como una cookie. Un mejor enfoque es utilizar una función como random() para generarlo en el servidor. Creo que los programadores todavía tienen este conocimiento, así que no entraré en detalles.