Regex per verificare se un percorso solo scendere

Question

Voglio testare se un percorso dato dall'utente andare giù come:

my/down/path

al contrario di:

this/path/../../go/up

per motivi di sicurezza.

Ho già fatto questo:

return (bool)preg_match('#^([a-z0-9_-])+(\/[a-z0-9_-])*$#i', $fieldValue); 

Ma l'utente dovrebbe essere consentito di utilizzare l''.' nel suo percorso (come: my/./path, che non è utile ma lui può) e non so come considerare esso.

Sto quindi cercando una regex sicura per verificare questo.

Grazie

EDIT: Dopo aver visto le risposte, sì sarebbe bene se il controllo di prova se il percorso vero e proprio (rimozione '.' e '..') è un percorso verso il basso.

Answer 1

Probabilmente non si desidera controllare che un percorso non contenga .. ma si desideri invece controllare che, se valutato come intero, non salga. Per esempio. ./path/.. è ancora in ., anche se contiene ...

È possibile trovare un'implementazione di path depth validation in Twig:

$parts = preg_split('#[\\\\/]+#', $name); 
$level = 0; 
foreach ($parts as $part) { 
    if ('..' === $part) { 
     --$level; 
    } elseif ('.' !== $part) { 
     ++$level; 
    } 

    if ($level < 0) { 
     return false; 
    } 
} 

return true; 

Ramoscello non utilizzare realpath per la validazione, perché realpath ha problemi con i percorsi in archivio Phar. Inoltre, realpath funziona solo se il percorso esiste già.

Answer 2

$folders = $explode('/', $path); 

if (in_array('..', $folders)) { 
    print('Error: path contains ..'); 
} 

Answer 3

si può semplicemente verificare se la realpath del percorso utente fornito inizia con il percorso consentito:

function isBelowAllowedPath($allowedPath, $pathToCheck) 
{ 
    return strpos(
     realpath($allowedPath . DIRECTORY_SEPARATOR . $pathToCheck), 
     realpath($allowedPath) 
    ) === 0; 
} 

Demo on codepad

Si noti che questo sarà anche tornare false per le directory che non esistono sotto $allowedPath.

Answer 4

Se si desidera solo impedire all'utente di salire nella gerarchia percorso, è possibile cercare in modo esplicito '..':

if (1 === preg_match('/\.\./', $path)) { 
    /* path contains .. */ 
} 

che è anche più veloce di esplodere e in_array.

Benchmarking:

<?php 

$attempts = 100000; 
$path  = 'my/path/with/../invalid'; 

$t = microtime(true); 
for ($i = 0; $i < $attempts; ++$i) { 
    $folders = explode('/', $path); 
    if (in_array('..', $folders)) { 
    /* .. in path */ ; 
    } 
} 
$end = microtime(true); 
printf("in_array: %f\n", $end - $t); 

$t = microtime(true); 
for ($i = 0; $i < $attempts; ++$i) { 
    if (1 === preg_match('/\.\./', $path)) { 
    /* .. in path */ ; 
    } 
} 
$end = microtime(true); 
printf("preg_match: %f\n ", $end - $t); 

in_array: 0,088750

preg_match: 0.071547

Answer 5

Le risposte precedenti (inclusa quella accettata) profondità del percorso indirizzo ma non percorso trasversale. Poiché la domanda specificava esplicitamente che questo è per la sicurezza, il controllo casuale come quello descritto finora potrebbe non essere sufficiente.

Per esempio,

• vi preoccupate per l'attraversamento tramite link hard o soft sotto la directory di lavoro corrente?
• Il sistema su cui ci si trova (o potrebbe potenzialmente distribuire) supporta l'Unicode?
• Quante cose stanno valutando la stringa in questione prima o dopo che il codice PHP la vede? Il server web? Il guscio? Qualcos'altro?

Supponiamo di inviare una stringa al tuo script come ./..%2f../? È importante per la tua applicazione che questa stringa mi porterà su due livelli? O che gli script forniti in altre risposte non prenderanno questo perché non valutano a ..?

Che dire di ./\.\./? Se il percorso viene analizzato dividendo su entrambi i valori \ e /, lo script nella risposta accettata non lo catturerà perché ogni parte avrà l'aspetto di . che è semplicemente la directory corrente. Ma una tipica shell UNIX tratta lo \ come un carattere di escape, quindi passarlo a ./\.\./ equivale a ./../ e così l'utente malintenzionato può sfruttare il fatto che lo script combina i test per i percorsi di stile UNIX e Windows.

Se per "sicurezza" si intende realmente che si desidera fornire protezione contro errori casuali e errori di battitura, allora le altre risposte sono probabilmente sufficienti. Se si sta programmando per un ambiente ostile e si desidera prevenire violazioni da attacchi intenzionali, si graffiano a malapena la superficie e si consiglia di leggere la programmazione sicura su OWASP. Vorrei iniziare con il loro articles on Path Traversal e poi leggere sugli altri attacchi che hanno delineato e su come evitarli e, cosa più importante, come testarli.