Path Truncation non funziona in PHP durante lo sfruttamento di LFI

Question

Path Truncation non funziona in PHP durante lo sfruttamento di LFI

Naviga le tue risposte

#1 da (1 voti)

1

Da quanto ho capito in PHP '/ etc / passwd /' o '/etc/passwd/./././' dovrebbe essere trattato come '/ etc / passwd'

Sto usando PHP 5.4 e questo non sembra essere vero:

php -r "include('/etc/passwd'); "

funziona bene ma

php -r "include('/etc/passwd/'); "

Warning: include(/etc/passwd/): failed to open stream: No such file or directory in Command line code on line 1

Warning: include(): Failed opening '/etc/passwd/' for inclusion (include_path='.:') in Command line code on line 1

Lo stesso vale per:

php -r "include('/etc/./././passwd'); "

opere!

php -r "include('/etc/./././passwd/'); "

Warning: include(/etc/./././passwd/): failed to open stream: No such file or directory in Command line code on line 1

Warning: include(): Failed opening '/etc/./././passwd/' for inclusion (include_path='.:') in Command line code on line 1

non funziona!

Qualcuno può farmi sapere se sto facendo qualcosa di sbagliato o è stato risolto il problema del troncamento del percorso?

php web-application

posta DimDim 25.05.2014 - 17:04

fonte

1 risposta

Leggi altre domande sui tag php web-application

Accesso relay periodico Postfix negato I nomi delle directory che utilizzano le estensioni rappresentano un rischio per la sicurezza?

score 1 · Accepted Answer

La ricerca "Realpath" è stata completamente rinnovata in questo commit il 12 agosto 2008, in un modo non è più vulnerabile all'attacco del troncamento del percorso. Queste modifiche sono state rilasciate in PHP 5.3.0, quindi nessuna versione più recente sarà vulnerabile (a meno che il bug non sia stato reintrodotto, il che non sembra essere avvenuto).

Per inciso, non vi è alcuna indicazione che qualcuno abbia mai avvisato gli sviluppatori PHP di questo attacco o che la correzione per questo attacco sia stata deliberata - sembra effettivamente che sia stato corretto come sottoprodotto della correzione di un altro bug.

Inoltre, se usato con NGINX e FastCGI, PHP è ancora vulnerabile a un attacco simile in cui l'interprete PHP elaborare una richiesta dal webserver anche se il nome del file ha qualcosa in più alla fine. Tuttavia, il comportamento che consente questo attacco è di design sia in NGINX che in PHP, quindi l'unico modo per proteggerlo è utilizzare una delle cinque soluzioni alternative elencate.