Test della vulnerabilità null byte

Sto aiutando il mio amico a finire il suo modulo per un sito web. Dalla mia prima impressione guardando i suoi moduli, ho trovato alcune cose molto pericolose, ma lui dice che questo metodo è sicuro. file esiste (inc/test/bar.php);:Test della vulnerabilità null byte

Parte del codice:

session_start(); 

    if(isset($_POST['foo'])) 
    { 
    $_SESSION['foo'] = $_POST['foo']; 
    } 

    if(isset($_SESSION['foo'])) 
    { 
    $foo['foo'] = $_SESSION['foo']; 
    } 

    if(is_file("inc/". $foo['foo'] . "/bar.php")) { 
    // code 
    } 
    else { 
    // code 
    }

Nota

ho voluto mettere alla prova il suo codice, e ho mandato le seguenti richieste:

POST :: foo => test/bar.php% 00

POST :: foo => test/bar.php \ 0

curl_setopt ($ ch, CURLOPT_POSTFIELDS, 'foo = test/bar.php'. chr (0x00));

Ma nessuno di questi metodi ha funzionato. Questo codice è davvero sicuro? e come qualcuno potrebbe inviare un byte null per bypassare la sua sicurezza. Voglio dimostrare al mio amico che il suo codice non è sicuro.

fonte

2013-05-03 John

Non sono un esperto di php quindi lascerò questo come commento, ma non potresti passare qualcosa come "../../. ./../ "e ottenere un accesso arbitrario al file system? –

@ChrisThompson ha "/bar.php" alla fine quindi controllerà ../../../bar.php in tutti i casi – John

ok, quindi è solo una minaccia se si sta potenzialmente accedendo a _some altro_ ' bar.file php' che non dovresti accedere a –

ho trovato this soluzione, insomma, sembra proprio codice è un po 'vulnerabili, e il metodo di sanificazione è questo:

Ci sono un certo numero di modi per prevenire veleno iniezioni byte null all'interno PHP. Questi includono la fuga il byte NULL con un backslash, però, il modo più consigliato per farlo è quello di rimuovere completamente il byte utilizzando il codice simile al seguente:

$foo['foo']= str_replace(chr(0), '', $foo['foo']);

Io non sono anche un esperto in attacchi null-byte, ma questo ha senso. Ancora più dettagli here.

fonte

2013-05-03 19:54:11 Shomz

L'OP dovrebbe anche sostituire il carattere null byte quando si salva il valore da '$ _POST' nella sessione! Ciò impedisce un possibile riutilizzo successivo e non sicuro di '$ _SESSION ['pippo']'. – ComFreek

-3

Php è molto vurnable per i byte Null .... perché php è costruito su c. In c un byte null indica la fine della stringa.

È necessario rimuovere i byte Null su ogni stringa utilizzata. Ciò è ancora più importante nelle funzioni basate su IO come include en move_uploaded_file.

Anche (int) "1 \ 01" è vurnable perché mette in int 1

funzioni PHP che può gestire byte Null sono per esempio

str_replace strpos STRLEN

Anche database querys. Mysql è vurnable su per byte Null su char, varchar e colonne di testo

fonte

2013-05-17 17:26:57

Questo non è più vero per PHP 5.3.4 e versioni successive. (Che sono tutte le versioni attuali.) – duskwuff

In realtà, un mucchio delle cose seguenti è solo falso. Le funzioni di gestione delle stringhe di PHP (come 'strlen()') funzionano perfettamente su stringhe che includono byte nulli, così come MySQL. – duskwuff

Grazie per -1 vai anche su php 5.4 la funzione include si romperà con un byte Null ed eseguirà SELECT "ciao \ 0there" quindi vedrai .. –

Test della vulnerabilità null byte

risposta

Problemi correlati