Potencjalne problemy bezpieczeństwa z ZipArchive PHP

Question

Chcę umożliwić członkom opcję przesyłania treści za pomocą pliku zip. Po przesłaniu chcę użyć klasy ZipArchive PHP, aby rozpakować zawartość pliku zip do katalogu, a następnie przenieść pliki do naszego systemu.

Jestem zaniepokojony potencjalnymi zagrożeniami bezpieczeństwa i nie mogę znaleźć żadnej dokumentacji na php.net. Pierwszym (cóż, jedynym) ryzykiem, które przychodzi na myśl, jest ktoś, kto tworzy plik zip ze względnymi ścieżkami, jak "../../etc/passwd" (Jeśli założą, że rozpakuję plik w/tmp/somedir).

Naprawdę ciężko jest utworzyć względną ścieżkę w pliku zip, więc nie mogę sprawdzić, czy coś takiego byłoby możliwe. Nie mogę też znaleźć sposobu na wyodrębnienie zawartości pliku zip przy pomocy ZipArchive i zignorować katalogi (rozpakować wszystkie pliki, ale nie tworzyć struktury katalogów wewnątrz zip).

Czy ktoś może mi powiedzieć, czy taki exploit jest możliwy i/lub jak zignorować strukturę katalogów w pliku zip za pomocą ZipArchive?

Answer 1

W końcu idę z rozwiązaniem Pekka, używając narzędzia unzip wiersza poleceń. Zapewnia przełączniki do ignorowania katalogów w pliku zip. Obawy, o których inni zwrócili uwagę, nie stanowią tutaj problemu. Po rozpakowaniu plików dodajemy je do systemu, wykorzystując ten sam proces co nasze zwykłe przesyłanie, co oznacza, że ​​każdy plik jest sprawdzany za pomocą środków bezpieczeństwa, które już mamy.

Answer 2

Należy upewnić się, że wyodrębniona zawartość nie jest obsługiwana bezpośrednio przez serwer aplikacji. Więc jeśli ktoś ma plik php w swoim archiwum, nie może go wykonać przez twój serwer WWW.

Inną sprawą jest ochrona zawartości przed treściami generowanymi przez użytkowników. Ale należy to wziąć pod uwagę również bez archiwów zip.

Answer 3

Interesujące pytanie, ale zachęcam do podjęcia tej decyzji w inny sposób. Gorąco polecam uruchomić proces sieciowy z najmniejszymi przywilejami w chrootowanym więzieniu. Zakładając, że to zrobisz, najgorszą rzeczą, jaka może się stać, jest uszkodzenie Twojej witryny, a następnie przywrócenie kopii zapasowej i wykonanie analizy kryminalistycznej w celu podłączenia tej konkretnej dziury. Nowe dziury są odkrywane ciągle, będziesz miał bardzo trudny czas, całkowicie zabezpieczając swoją stronę po takich przeczuciach. Zminimalizowanie piaskownicy napastnika naprawdę ma długą drogę.

Answer 4

miałem te same problemy i musiał zapoznać się z kodu źródłowego PHP 5.3, gdzie znalazłem to:

/* Clean/normlize the path and then transform any path (absolute or relative) 
     to a path relative to cwd (../../mydir/foo.txt > mydir/foo.txt) 
*/ 
virtual_file_ex(&new_state, file, NULL, CWD_EXPAND TSRMLS_CC); 
path_cleaned = php_zip_make_relative_path(new_state.cwd, new_state.cwd_length); 
if(!path_cleaned) { 
    return 0; 
} 

wygląda dobrze do mnie. Sprawdź kod PHP i zobacz ./ext/zip/php_zip.c, aby uzyskać szczegółowe informacje.