Una vulnerabilità comune è che le applicazioni Web accettino un percorso del file system come parametro di richiesta e quindi eseguano alcune azioni sul percorso specificato. Ad esempio, il recupero di un file e il suo invio all'utente, o forse anche la scrittura / eliminazione di un file. Questo può consentire agli utenti malintenzionati di accedere a file a cui non dovrebbero essere in grado di accedere, come codice sorgente, file password, ecc.
Questo può essere un problema anche se si antepone un percorso di base, poiché un utente malintenzionato può utilizzare sequenze di attraversamento di directory come ../ (* nix) e ..\ (Windows) per attraversare il percorso di base e limitarsi a directory e file.
L'idea generale, quindi, è quella di escludere a titolo definitivo tali sequenze di attraversamento, o di "normalizzare" i percorsi contenenti questi sequenze e quindi verificare che siano ancora all'interno del percorso di base.
Da quanto ho capito, cercare di inserire nella blacklist sequenze trasversali nel parametro request è difficile, perché esistono codifiche URL e Unicode alternative (ad esempio %2e%2e%2f e molti , molti altri) che potrebbero finire per essere interpretati dal web server come ../ o ..\ .
Tuttavia, le codifiche alternative sono ancora un problema se normalizziamo il percorso dopo che è stato ricevuto dal server web (ad es. Apache) e passato alla mia applicazione? Ad esempio, utilizzando queste regole di normalizzazione ?
Il mio ragionamento è che, se il web server riceve %2e%2e%2f e lo decodifica a ../ , o il web server riceve direttamente ../ , l'algoritmo di normalizzazione vedrà ../ e lo risolverà / filtrerà prima di verificare contro la directory di base. Anche se un utente malintenzionato utilizza una doppia codifica come %252e%252e%252f , verrà decodificato come %2e%2e%2f , che verrà trattato letteralmente dal sistema operativo / file system.
Tuttavia, in questa domanda , suggerisce che :
However, if a web server is serving files and decoding the unicode is done after the check that prevents directory traversal or done slightly differently by the operating system, this attack may get past the filter allowing the attack to work.
Quindi, in altre parole, ci sono sequenze di caratteri noti che potrebbero superare la decodifica del server Web E la routine di normalizzazione summenzionata (che gestisce ../ o ..\ ), che potrebbe essere interpretata dal sistema operativo o inferiore -leveloce gestione dei file funziona come directory traversal?
Ad esempio, in 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);