[php] Załącznik wgrywany na serwer. Jakie rozszerzenia dopuszczać?, Czy ograniczać użytkownikom format ładowanych plików? Opcje

[luis2luis]

Witam.
Piszę mechanizm do wysyłania wiadomości pomiędzy poszczególnymi użytkownikami. Zalaczniki sa ladowane na serwer.

Czy mam w jakiś sposób ograniczać format ładowanych plików?
Czy folder do którego ładuje pliki musi mieć odpowiednie uprawnienia? tzn brak wykonania? Proszę o podpowiedź.

Chce za wszelką cenę uniknąć możliwość ataku na strone.

[Niree]

No tak. Plik, który tworzy kolejne pliki musi mieć odpowiednie chmody.

Rozszerzenia najlepiej te znane, typu jpeg, jpg, png, txt, doc.
Albo wyklucz php, js, html, xml i inne.

[viking]

A co mają chmody do tego? Plik żeby dało radę go wyświetlić musi być co najmniej do odczytu. A skoro tak to można go dowolnie wykonać.

[luis2luis]

A co mają chmody do tego? Plik żeby dało radę go wyświetlić musi być co najmniej do odczytu. A skoro tak to można go dowolnie wykonać.

Z tego co mi wiadomo , to chmod matrzy poziomy "zezwoleń" CZYTAJ -> ZAPISZ -> WYKONAJ.
Wykonaj to nie jest "obsłuż przez parser php"? Albo inaczej, Bez opcji wykonaj, plik jest zwracany jako czysty tekst bez przetwarzania?


CHMOD GENERATOR

[viking]

Zależy od konfiguracji serwera. Jeśli np pracuje jako Fastcgi skrypt deleguje wykonywanie do procesu.

[luis2luis]

No tak. Plik, który tworzy kolejne pliki musi mieć odpowiednie chmody.

Rozszerzenia najlepiej te znane, typu jpeg, jpg, png, txt, doc.
Albo wyklucz php, js, html, xml i inne.

to że plik musi mieć mołżiwośc zapisu. ale nto nie jest problem.

Problem jest, że ktoś mi uploaduje plik php i wykona sobie swój kod.

No tak. Plik, który tworzy kolejne pliki musi mieć odpowiednie chmody.

Rozszerzenia najlepiej te znane, typu jpeg, jpg, png, txt, doc.
Albo wyklucz php, js, html, xml i inne.

Tak, tylko, że jest jeszcze *.docx, *.xlsx, i mase inych z samego pakietu office, dodatkowo *.php4, *.php5, *.php7 i ciul wie co jeszcze ktoś możewymyśleć.

[viking]

Sprawdzanie masz robić po content-type a nie rozszerzeniach.

[Pyton_000]

samo content-type też nie jest bezpieczne. Bo taki np. pliczek JPG może mieć zaszyty wykonywalny kod.

[viking]

To tak na początek

[luis2luis]

samo content-type też nie jest bezpieczne. Bo taki np. pliczek JPG może mieć zaszyty wykonywalny kod.

Datego chce odgórnie zablokować wszystko co może być wykonalne na serwerze.

Pokolei poprawiam bezpieczeństwo poszczególnych elementów systemu i teraz przyszedłczas na to upload plików.
Bede chciał na stronie uruchomić na użytkowników manager plików, żeby mogli zarządzać swoimi plikami, tu tez bedzie podobna kwestia bezpieczeństwa.

[Pilsener]

Problem jest, że ktoś mi uploaduje plik php i wykona sobie swój kod.

Jeśli jest taka możliwość, to problem leży w aplikacji/konfiguracji serwera a nie w pliku. Bezpieczeństwo nie powinno być zależne od pliku i ratowanie się sprawdzaniem jego zawartości czy rozszerzenia to co najwyżej doraźna proteza.
Plik wrzucasz po prostu na serwer a gdy użytkownik chce go pobrać to aplikacja go odczytuje i mu wysyła - nie widzę tu żadnego zagrożenia.
Natomiast widziałem wiele razy, jak plik był walidowany na 50 sposobów (co powodowało frustrację użytkowników bo zawsze jakiś plik nie przechodził walidacji) po czym wrzucany do .... publicznego katalogu!

[krzywy5830]

Pisałem kiedyś taki upload plików, że użytkownik uploaduje plik i może komuś udostępnić do niego linka. Pliki trzymałem katalog wyżej niż public_html (nie na każdym serwerze to działa, zależy od konfiguracji, jeśli nie działa to można dać .htaccess z deny from all w folderze z plikami). Poza tym każdy plik dostawał losową nazwę i był przechowywany na serwerze bez rozszerzenia, np. ktoś wgrał plik "ziemniak.php: a na serwerze był przechowywany jako "jiofjwefwf4we6504v6870ef". Wszystkie informacje o plikach (takie jak jego prawdziwa nazwa i rozszerzenie) były przechowywane w bazie danych. Do pobierania plików napisałem sobie skrypt download.php, w którym przesyłałem odpowiednie nagłówki i takie tam. Dzięki temu żaden Janusz nie dobierze się do pliku korzystając z adresu np. www.strona.pl/upload/ziemniak.php i nie wywoła żadnego złośliwego kodu. Aby dobrać się do pliku trzeba było użyć adresu www.strona.pl/download.php?id=69. Skrypt download.php zamiast wywoływać kod zawarty w pliku ziemniak.php od razu go pobierał na komputer użytkownika lub w przypadku gdy był to obrazek lub plik .pdf to wyświetlał go w przeglądarce (sprawdzanie typu MIME i odpowiednie instrukcje warunkowe).