Una vulnerabilidad común es que las aplicaciones web acepten una ruta del sistema de archivos como un parámetro de solicitud y luego realicen alguna acción en la ruta especificada. Por ejemplo, recuperar un archivo y devolverlo al usuario, o tal vez incluso escribir / eliminar un archivo. Esto puede permitir a los usuarios malintencionados acceder a archivos a los que se supone que no deben poder acceder, como el código fuente, los archivos de contraseña, etc.
Esto puede ser un problema incluso si antepones una ruta base, porque un atacante puede usar secuencias transversales de directorios como ../ (* nix) y ..\ (Windows) para desplazarse hacia arriba fuera de la ruta base y hacia restringido directorios y archivos.
La idea general, entonces, es prohibir cualquiera de estas secuencias transversales, o "normalizar" las rutas que contienen estas secuencias y luego verifique que aún estén dentro de la ruta base.
Por lo que entiendo, tratar de incluir en la lista negra las secuencias transversales en el parámetro de solicitud es difícil, porque existen codificaciones URL y Unicode alternativas (por ejemplo, %2e%2e%2f y many , many others) que el servidor web puede interpretar como ../ o ..\ .
Sin embargo, ¿las codificaciones alternativas siguen siendo un problema si normalizamos la ruta después que ha sido recibida por el servidor web (por ejemplo, Apache) y se ha pasado a mi aplicación? Por ejemplo, usando estas reglas de normalización ?
Mi razonamiento es que, ya sea que el servidor web reciba %2e%2e%2f y lo decodifique a ../ , o el servidor web reciba directamente ../ , el algoritmo de normalización verá ../ y lo resolverá / filtrará antes de comparar El directorio base. Incluso si un atacante usa una codificación doble como %252e%252e%252f , se descodificará como %2e%2e%2f , que será tratado literalmente por el sistema operativo / sistema de archivos.
Sin embargo, en esta pregunta , sugiere que :
Sin embargo, si un servidor web está sirviendo archivos y decodificando, el Unicode se realiza después de la verificación que impide el cruce del directorio o el sistema operativo lo hace de forma ligeramente diferente, este ataque puede pasar el filtro y permitir que el ataque funcione.
En otras palabras, ¿existen secuencias de caracteres conocidas que puedan superar la decodificación del servidor web Y la rutina de normalización mencionada anteriormente (que maneja ../ o ..\ ), que podría ser interpretada por el sistema operativo o inferior? -el nivel de gestión de archivos funciona como el recorrido del directorio?
Por ejemplo, en PHP:
$base = "/path/to/allowed/directory/";
$path = $_GET['path'];
$normalizedPath = normalize($path); // normalize will remove or resolve ../ and ..\
$fullPath = $base . $normalizedPath;
echo file_get_contents($fullPath);