Ostatnio zapytano mnie co zrobić w wypadku, gdy użytkownik będzie próbował uploadować zawirusowane zdjęcie na serwer (poprzez funkcję move_uploaded_file() lub copy() ). Szczerze mówiąc nigdy wcześniej nie przyszła mi taka ewentualność do głowy.
Czy rzeczywiście jest to realne zagrożenie? A jeśli tak jakie są możliwości zabezpieczenie strony/serwera przed taką sytuacją?

Hmm... nie wydaje mi się aby było możliwe umieszczenie wirusa w obrazku. Co prawda istnieją pewne metody "chowania" danych w plikach graficznych ale w tedy mogą mieć one co najwyżej nazwę obrazek.jpg.EXE(!) więc wydaje mi się, że wystarczy sprawdzać rozszerzenie uploadowanego pliku za pomocą funkcji pathinfo i tyle. Oczywiście zaznaczam, że nie jestem żadnym specjalistą i mogę się milić.

zdjęcia nie da sie zawirusować. plik wykonywalny musi miec rozszerzenie: *.exe, *.msi, *.com. oczywiscie uzytkownik może zamienic 'exe' na -> 'jpg' ale wtedy "wirus" sie nie uruchomi tylko wyskoczy komunikat w stylu "zdjecie jest uszkodzone"

Była dziura w SMF 1.1.8, która umożliwiała wykonanie kodu wstrzykniętego w metadane obrazka.

Jak zabezpieczyć? Wycinać metadane na serwerze. Wystarczy ImageMagick, dowolne polecenie i pewien parametr, na który na pewno trafisz.

dodatkowa kompresja na serwerze powinna usunac potencjalne smieci

Da się wrzucić wirka do zdjęcia. To kwestia wpisania odpowiednich danych do struktury pliku. Najczęściej komentarzy zdjęcia w EXIF. Oczywiście nie mówię nawet o sytuacji, gdy zapisuje się skrypt cały po prostu zmieniając mu rozszerzenie na jpg czy gif A jak można się tego "pozbyć"? Choćby wczytując plik przez biblioteki do obróbki zdjęć jak ImageMagick lub GD i zapisując je ponownie. Większość z danych wtedy ulega utracie i na dodatek można wykryć, czy rzeczywiście mamy do czynienia ze zdjęciem czy może tylko z "podróbką".

I po co sobie pogarszać jakość zwiększając dodatkowo rozmiar pliku?

Są funkcję do usuwania metadanych z obrazów, to trzeba z nich korzystać, a nie szukać rozwiązań (obejść).

bardziej chodzilo mi o "kompresje" bez pogarszania parametrow grafiki (w stylu: te same wymiary 100% dla jpg, ta sama liczba kolorow itp)
thek lepiej to ujal (wczytanie i zapis)

Hej. Ja prowadzę (udanie) hosting zdjęć ifotos.pl. Już 2 dnia ktoś włamał mi się na serwer, miałem wtedy tylko sprawdzany mime type. Dziś mam sprawdzanie mime-type, rozszerzenie i to wszystko. Przez ponad rok serwis nie został popsuty Polecam więc sprawdzanie zarówno rozszerzenia jak i typu pliku (mime type)

Muszę Cię rozczarować - spowoduje to właśnie pogorszenie jakości.

sory za lekki spam, ale erix ma rację, z resztą nie kłuć się z osobą posiadającą certyfikat zenda (szacun ). Ale tak przy okazji, jeśli erix mówisz o funkcji usuwania meta tagów to jaka to funkcja co? powiedz

Jak mniemam kod PHP można umieścić i bezpośrednio w obrazku - co prawda nie będzie już działał, ale bez weryfikacji poprawności i tak przejdzie. Muszę zerknąć do źródeł funkcji getimagesize() - bo nie sądzę żeby samo jej stosowanie (a tak chyba jest w wielu przypadkach) wystarczyło. Niemniej nawet posiadając kod w obrazku zupełnie nic nie możemy z nim zrobić - potrzebna jest dużo poważniejsza dziura typu local file inclusion.

kod PHP możesz umieścić (ale tylko kiedy masz tak ustawione na serwerze) standardowo żaden kod (poza plikami .php) nie jest wykonywany.

~MWL, papier to nie wyznacznik.

A wracając do tematu - kiedyś robiłem ciut głębsze badanie na temat tej przypadłości. getimagesize nie sprawdza, czy są doklejone do pliku jakieś dane. Wynika to z tego, że w GIF/PNG wymiary są zapisane bodajże w nagłówku i po prostu dalsza część pliku nie jest potrzebna. Jeśli chodzi o JPG, jest to związane z konkretnymi blokami i dalej plik nie jest już czytany. W zasadzie wystarczy pierwsze pół kilobajta pliku (nawet uciętego), aby getimagesize nie zwróciło błędu.

Jeśli chodzi o możliwość wykorzystania tego kodu - była swego czasu luka w SMF, która zamieniała serwery w istne armaty do spamowania (tak nawiasem, pliki maskowały się w katalogach TinyMCE ). O ile w sytuacji, gdy obrazki są tylko dla nas, to nie ma ryzyka (zakładam, że nie będzie wykorzystywane PHP do ich wyświetlania), to w przypadku, gdy coś z nimi robimy (wyświetlanie przez readfile i pochodne) już stwarzało problemy.

Nie mam 100% pewności, ale na atak narażone są konfiguracje, w których PHP działa jako aplikacja (Fast)CGI.


No i tu jest pies pogrzebany - niestety nie masz racji. Serwer nie sprawdza (to jest jedna z głównych przypadłości bezpieczeństwa wykonania skryptów interpretera PHP), jakie rozszerzenie jest wykonywane. Wystarczy nadpisać tablicę MIME i nawet ten spreparowany obrazek się wykona jako skrypt.


ImageMagick, dowolne polecenie, parametr -strip: http://www.imagemagick.org/script/command-...tions.php#strip

W jaki sposób nadpisać tablicę MIME za pomocą spreparowanego obrazka?

Nie pamiętam już, na czym konkretnie polegał ten bug, ale AFAIR był on powiązany z tą przypadłością (brakiem sprawdzania rozszerzenia wykonywanego skryptu).