Ci può essere un modo per sfruttare PHP include_once () quando l'input viene filtrato?

Question

Ci può essere un modo per sfruttare PHP include_once () quando l'input viene filtrato?

#1 da (5 voti)
#2 da (2 voti)
#3 da (2 voti)

6

Supponiamo che ci sia questo codice per includere altri file php dall'input dell'utente (sì, so che è una cattiva scelta):

$input = addslashes($_GET["input"]);

if (strpos($input, '../') === false) {
    include_once('/path/to/php/files/'.$input);
} else { echo('Invalid parameter!'); }

Questo codice aggiunge barre a virgolette singole e doppie, quindi controlla ../ nella stringa e, se non lo trova, include il file.

Supponendo che l'hacker abbia scritto del codice da includere in un'altra cartella e che l'hacker abbia bisogno di accedere a quel file con ?input=../../folder/extcode , può esserci una vulnerabilità qui?

php rfi lfi

posta Moonsik Park 04.11.2018 - 09:55

fonte

3 risposte

Leggi altre domande sui tag php rfi lfi

Esiste il rischio di tentare l'autenticazione ssh su un server canaglia? Come determinare e controllare l'estensione dei dati che passano attraverso la connessione VPN?

score 5 · Answer 1

5

Questo codice è vulnerabile a LFI quando è in esecuzione su sistemi Windows, poiché tali sistemi accettano un percorso contenente un attraversamento di directory che utilizza barre rovesciate (come \..\..\ ).

risposta data 05.11.2018 - 02:19

fonte

score 2 · Answer 2

Quello che stai cercando di bloccare è un LFI, ma penso che tu sia ancora vulnerabile. Questo tipo di scenari di solito sono potenzialmente vulnerabili a LFI e RFI.

Sembra che il tuo codice non sia vulnerabile a RFI a causa del prefisso del percorso locale. (Link a LFI e RFI: link ).

Solo per chiarimenti, su RFI l'attaccante proverà ad includere un file remoto usando un carico utile come http://evilsite/evil.php e come puoi vedere non contiene '../' su di esso. Per proteggerlo, devi configurare sul tuo php.ini il allow_url_include e accertarti che sia disattivato. Altrimenti potresti essere hackerato usando RFI a seconda dell'input. Quindi è una buona pratica disattivarlo se non necessario.

Parlando di LFI, penso che il tuo codice non sia sicuro. Ok, stai bloccando stringhe come '../' ma forse l'hacker potrebbe codificarlo in qualche modo per bypassare la tua protezione. Come @ game0ver ha detto in un commento, l'autore dell'attacco potrebbe usare la codifica base64 o url e forse di più. Stai attento!

Quindi riassumendo. Sei NOT vulnerabile a RFI ma, YES probabilmente sei vulnerabile a LFI .

score 2 · Answer 3

RFI e LFI

Purtroppo, questo non sembra essere direttamente sfruttabile. Come discusso altrove nei commenti, RFI non è possibile a causa del prefisso, e LFI non è possibile in linux perché (credo) non c'è modo di sfuggire al strpos tramite la codifica. PHP decodificherebbe automaticamente qualsiasi stringa codificata URL prima di inserirla nella super variabile $_GET e qualsiasi codifica che non attivasse la ricerca strpos non verrebbe registrata come una barra diretta ai fini della chiamata di inclusione (a almeno, non sono riuscito a trovare alcun vettore di attacco riuscito). Tieni a mente la risposta di duskwuff però - LFI è possibile qui su Windows.

Attacchi alternativi

Tuttavia, ciò non significa che non possa aiutare. In particolare, open include in questo modo il tipo di vulnerabilità che consente di rendere una vulnerabilità più piccola molto più grande. Il pensiero immediato che viene in mente è quello di verificare se questo sito ha una funzione di upload delle immagini ovunque. Se è così, e sai dove vengono salvate le immagini, puoi provare ad inserire PHP valido nei dati EXIF di un'immagine jpg che poi carichi sul server. Normalmente tale codice non è sfruttabile, perché non hai comunque il permesso di eseguire il tuo PHP sul server. Tuttavia, con un inclusivo aperto come questo, puoi caricare il tuo file e quindi utilizzare questa vulnerabilità per eseguirlo (dal momento che probabilmente il file caricato esiste all'interno di /path/to/php/files la mancanza di una vulnerabilità LFI pienamente qualificata non avrà importanza). Da lì puoi fare quello che vuoi.

Usare l'input dell'utente per costruire un percorso di inclusione è quasi sempre una cattiva idea, ed è raramente necessario. Anche se non c'è una debolezza immediata, ciò non significa che non possa aiutarti quando ne sfrutti altri.

Migliore sicurezza

Penso che valga la pena di dedicare un minuto a spiegare come qualcosa come questo dovrebbe essere protetto. È difficile fornire una soluzione esatta senza più contesto, ma in genere qualcosa di simile può essere suddiviso in un processo in due fasi più sicuro:

Utilizza realpath per consentire al sistema di risolvere tutti i tentativi di attraversamento di directory e ottenere un percorso assoluto finale
Assicurati che il percorso assoluto finale risieda in una directory sicura per poter includere i file da, o esplicitamente white-list contro un elenco di include sicuri

Non vuoi mai consentire all'utente di includere un file arbitrario. Determinare esattamente quale file verrà incluso come risultato dell'input dell'utente e filtrarlo attraverso una whitelist. Questo è l'unico modo per farlo in modo sicuro.