Witam

Istnieje możliwość zapisania w exif tags obrazka kodu php co może być niebezpieczne.
Napisałem bardzo prosty skrypt do sprawdzania kodu php w obrazkach i mam prośbę o sprawdzenie czy ten kod wystarczy, sprawdzałem kod i rzeczywiście odróżnia
obrazek z niebezpiecznym kodem od zwykłego obrazka ale może ktoś z was ma inne zdanie i wie jak oszukać ten skrypt ?

[PHP] pobierz, plaintext 
$get = file_get_contents( $_FILES['img']['tmp_name'] );
 
 
 
    $pattern = '/<?php./';
 
if(    preg_match($pattern,$get, $matches, PREG_OFFSET_CAPTURE)     ){
 
        echo' obrazek z kodem php ';
 
}
else{
 
        echo' nie ma kodu php';
 
}
[PHP] pobierz, plaintext 

Pomijam resztę zabezpieczeń post jest tylko o exif tags. Bardzo fajny artykuł na ten temat jest tutaj http://php.webtutor.pl/pl/2011/04/11/code-...w-obrazku-jpeg/ ale nie ma tam info jak wykryć niebezpieczny kod.

Żartujesz sobie, prawda?

czemu miałbym żartować ? jeżeli ktoś zapisze w exif tags obrazka kod php a ktoś ten obrazek wczyta funkcją include (tak nikt oczywiście nie robi) to kod php się wykona i nie wiem co w tym śmiesznego a ponieważ exif tags są zapisywane w fomie zwykłego textu to można to sprawdzić.

A Ty sobie żartujesz mówiąc, że on sobie żartuje? Prawda?

@daren88, musiałbyś sprawdzać obrazek pod kątem wszystkich możliwych otwierających i i zamykających tagów. (nie tylko tego jednego) Zakładam, że takie rzeczy jak sprawdzanie rozszerzenia obrazka, tego czy ma wymiary i czy jest prawdłowy (jest uploadowanym plikiem) już masz wprowadzone. Bo to są podstawy. To co Ty próbujesz wprowadzić to tylko dodatkowe umocnienie.

Nie żartuje. Osobiście widziałem atak, który polegał właśnie na wstrzykiwaniu kodu poprzez EXIF-y, wspominałem o tym też na phpconie.

Interpreter nie sprawdza rozszerzenia odpalanego pliku. Szuka wyłącznie ciągu do przeparsowania. Przemycić go nawet w binarce, to nie problem.

Któraś wersja SimpleMachines Forum 1.1x była podatna na ten atak.

Nie chodziło mi o samą możliwość takiego ataku, bo wiem, że takowa istnieje, a raczej o sposób rozwiązania problemu jako znalezienie otwierającego tagu <?php. Wydaje mi się, że to znacznie za mało, aby zmniejszyć ryzyko powodzenia tego typu ataku. Jeśli interpreter php obsługuje krótkie tagi czy tagi asp, to jest to marne rozwiązanie, bo kod zostanie prawdopodobnie wykonany. Do listy należałoby dodać jeszcze, o czym napisał już ~pyro:
<?
<%

Niebezpieczny nie jest sam kod doklejony do obrazka - niebezpieczne jest używanie include / require do wypluwania tych obrazków!
Także poza skleceniem filtra (fajnie wiedzieć, kto Ci próbuje wrzucić zainfekowany plik) warto przejrzeć skrypty pod kątem takiej podatności.

Obrazek z jakimś kodem nie będzie miał poprawnego mime/type. Jak ktoś sprawdza typy obrazków po ich rozszerzeniach a nie po mime/type to sam się prosi o problemy.

A nie wystarczy sprawdzać pierwszych 250 bitów obrazka??.To jest przykład początku obrazka zapisanego jako txt-gif'a .
GIF89ajp
÷ ÿÿÿ
To początek kodu obrazka jpeg:
ÿØÿà JFIF

mime/type można oszukać więc lepiej sprawdź twój kod. A jeżeli chodzi o mój skrypt to nie radze go używać zapomniałem o <? i <% ale niestety w połowie obrazków można znaleźć przypadkowe znaki <? bla bla bla ?> więc moja metoda odpada, a sam kod php w obrazkach nie jest szkodliwy jeżeli się go nie wykona np include czego nikt nie robi.

includowałeś kiedyś obrazek w kodzie php? Oo

Hah, nie trzeba require/include:

[APACHE] pobierz, plaintext 
AddType application/x-httpd-php .jpg
[APACHE] pobierz, plaintext 

i hulaj dusza.

Mime/type też można oszukać, nigdy nie masz pewności, co do rodzaju przesyłanego pliku. Kiedyś była obszerna dyskusja na ten temat na tym forum i niestety zakończyła się taką oto smutną konkluzją. Oczekiwanego rezultatu nie daje nawet sprawdzanie funkcją getimagesize poprawności nagłówka obrazka, bo i to można obejść, nie wspominając już o bardziej wyrafinowanych metodach type sprawdzenie typu pliku poleceniem systemowym file -ib <plik> gdyż to polecenie zachowuje się różnie na różnych wersjach systemów operacyjnych.

Nie, nie wystarczy.



Nie masz pojęcia o czym piszesz...

http://www.php.net/manual/en/function.imagick-stripimage.php

Nie pamiętam jak w GD.

Udowodnij.

Bo sprawdzanie tego z tablicy $_FILES, to proszenie się o problemy.


:

Gdyż sprawdza wyłącznie nagłówek i bloki, które mówią o rozmiarze obrazka. Resztę może stanowić nawet dump z /dev/urandom, a i tak przejdzie.

Otwórz sobie jakiegoś JPEG-a w jakimś lepszym notepadzie albo edytorze heksadecymalnym, utnij mu kilkaset bajtów tak, aby pozostał nagłówek nieruszony, dopisz coś i otwórz w przeglądarce albo sprawdź MIME. [;

Potem zabieraj głos. [;

Ja na twoim miejscu poświęcił trochę więcej czasu i zrobił następująco:

Czy znajduje się znak otwierający php
<? lub <?php

jeśli tak pobierasz dalszą część i sprawdzasz czy jest to kod php, bo tak jak pisałeś wcześniej czasami występują przypadkowe znaki <?
ale jest bardzo małe prawdopodobieństwo że wystąpi np. <? $
lub też tworzysz liste hexów czyli potencjalnych liter które mogły zostać użyte do stworzenia funkcji jeśli po tym znaku znajduje się pare hexów z listy pod rząd czy też jak tam to sobie wymyślisz to znaczy ze jest to php...
Jest to wsumie jakies tam zabezpieczenie bo wiadomo ze funkcja ani zmienna nie moze miec takich znakow &^%$%#*...

Mam nadzieje że dobrze myślę

Próbuje utworzyć plik ze skryptem javascript ,ale chyba źle coś robię ,czy ktoś może posiada taki plik,albo wie skąd można ściągnąć taki plik("tylko jakiś nie groźny-nie chciałbym mieć wirusów na kompie"), chciałbym przetestować swoją aplikację.

http://www.programosy.pl/program,exifeditor.html tym programem mozesz to zrobic
tutek jak: http://php.webtutor.pl/pl/2011/04/11/code-...w-obrazku-jpeg/
url zainfekowanego obrazka: http://php.webtutor.pl/wp-content/uploads/...-logo-virus.jpg
kod jaki sie w nim znajduje

[PHP] pobierz, plaintext 
<style>body{font-size: 0;} h1{font-size: 12px !important;}</style><h1><?php echo "<hr />THIS IMAGE COULD ERASE YOUR WWW ACCOUNT, it shows you the PHP info instead...<hr />"; phpinfo(); __halt_compiler(); ?></h1
[PHP] pobierz, plaintext 

Ten plik mi nie zadziała ja pisze w c#NET

No to dopisz sobie cos w C tam masz tutki powyzej jak to zrobic

a jscript tam można podpiąć ,czy tylko bloki serwerowe?

@erix już to zrobił

Puki co według tego przykładu ,zrobiłem plik w którym zamiast bloku <?php ?> dałem blok jscript.No i wykryło mi zły typ pliku-czyżbym miał dobrze zabezpieczone?

Znalazłem to w kodzie php-fusiona.. Sądze ze jest to rozwiazanie

[PHP] pobierz, plaintext 
// Scan image files for malicious code
function verify_image($file) {
	$txt = file_get_contents($file);
	$image_safe = true;
	if (preg_match('#&(quot|lt|gt|nbsp|<?php);#i', $txt)) { $image_safe = false; }
	elseif (preg_match("#&\#x([0-9a-f]+);#i", $txt)) { $image_safe = false; }
	elseif (preg_match('#&\#([0-9]+);#i', $txt)) { $image_safe = false; }
	elseif (preg_match("#([a-z]*)=([\`\'\"]*)script:#iU", $txt)) { $image_safe = false; }
	elseif (preg_match("#([a-z]*)=([\`\'\"]*)java script:#iU", $txt)) { $image_safe = false; }
	elseif (preg_match("#([a-z]*)=([\'\"]*)vb script:#iU", $txt)) { $image_safe = false; }
	elseif (preg_match("#(<[^>]+)style=([\`\'\"]*).*expression\([^>]*>#iU", $txt)) { $image_safe = false; }
	elseif (preg_match("#(<[^>]+)style=([\`\'\"]*).*behaviour\([^>]*>#iU", $txt)) { $image_safe = false; }
	elseif (preg_match("#</*(applet|link|style|script|iframe|frame|frameset)[^>]*>#i", $txt)) { $image_safe = false; }
	return $image_safe;
}
[PHP] pobierz, plaintext 

Według tego programu zrobiłem coś takiego:


Czy u Was przepuszcza w obrazkach ten kod-chodzi o to czy wyświetli alert.

Nie wiem nie sprawdzałem ale zaraz zobacze to ci powiem

Tak wyświetla... ale tylko jak zincludujesz ten plik...

masz błąd tam! nie masz cudzysłowia

[PHP] pobierz, plaintext 
<script type='text/javascript>
daj 
<script type='text/javascript'>
[PHP] pobierz, plaintext 

Mi po prostu w c# Net nie przepuszcza takich plików-zły typ pliku-mam dodatkową funkcję sprawdzającą typ pliku opierającą się o system operacyjny.To gra gitara -miałem lekkie obawy,że ta funkcja przepuści taką hybrydę,ale na szczęście tak nie jest.

kto wczytuje obrazki includem/requirem?

@erix miałeś rację

a co do systmowego file z linuxa, to też wskazuje na JPEG nawet po zmianie kodu wewnątrz, w sumie tego się nie da wykryć w łatwy sposób, chyba że wiemy czego szukamy.

Nie chodzi o to, że ktoś wczytuje obrazki przez require/include, ale o to jak można to wykorzystać jak w serwisie istnieje podatność typu File Inclusion

Oprócz sprawdzenia typu MIME można użyć funkcji getimagesize do sprawdzenia wymiarów obrazka, jeśli chociaż 1 parametr = 0 wiadomo, że nie jest to obraz.

Tylko właśnie problem jest w tym że to może być obraz... zawierający w sobie złośliwy kod...
np. DROP DATABASE

a gdyby posiadał rozmiary równe 0 czyli

[PHP] pobierz, plaintext 
<?
$roz = getimagesize("plik.php"); jak i $roz = getimagesize("plik.png");
var_dump($roz);
 
bool(false)
?>
[PHP] pobierz, plaintext 

to byś go wogóle nie sprawdził...

Nie wierze ,że nie ma na to rady jak w net.C# sobie z tym poradzili to i w php musi być na to sposób Inaczej to słynne Allegro po prostu już dawno temu przestałoby sobie istnieć.

Nie wiem ale to jest dość zaawansowana funkcja i sądze że skrypty pisane na php-fusionie równierz przestały by istnieć gdyby to nie chroniło ich wystarczająco...

Czyli ta funkcja verify_image to dobre zabezpieczenie?

Przede wszystkim trochę źle do tego podchodzisz. W obrazie może być ciąg bajtów odpowiadający przykładowo "<?php `rm / -rf`; ?>" ale czy to oznacza, że obraz zawiera "wirusa"? Nie. Dlaczego? Z tego samego powodu, dla którego ten post, który jest w bazie danych forum PHP.pl, nie jest wirusem mimo iż zawiera potencjalnie bardzo niebezpieczny kod.

Podstawą jest tutaj odpowiednie obchodzenie się z danymi. Podobnie jak nikt nigdy nie dopuści do tego by ten post (jego treść) została potraktowana evalem() podobnie Ty nigdy nie powinieneś dopuścić by obraz został potraktowany inaczej niż "do odczytu obrazu". Możesz oczywiście sprawdzać czy wgrywany obraz jest obrazem - czy da się go odczytać jako prawidłowy obraz zapisany w danym formacie, ale wyszukiwanie w nim "złośliwych" treści jest nieco bezcelowe.

Może są lepsze,ale lepsze takie niż wcale

Po jaką cholere wam te sprawdzanie ? Przecież i tak obrazy nie zostaną wczytane podczas wykonania skryptu PHP tylko dopiero potem doczytane zostaną przez klienta. Nie rozumiem w czym tutaj problem ? W jakiej sytuacji wg. was taki kod może zostać wykonany w skrypcie ? Pomijaj include/require bo nikt normalny tak nie wczytuje grafiki do kodu. Nawet gdyby udało się tam 'przemycić' kod w PHP to i tak nie ma możliwości wykonania go na serwerze, a jeżeli taka możliwośc jednak istnieje to NIE JEST to błąd w zabezpieczaniu uploadu obrazów tylko błednie napisany kod strony.

P.s-Tylko prosze was nie zasłaniajcie sie tym kodem z php-fusion'a.

Dobre
Taka regułka musiałaby zostać dopisana do konfiguracji Apache (np. do .htaccess), więc jeśli ktoś może już tyle zrobić, to po co ma się bawić w jakieś głupie obrazki z kodem PHP

To może jakoś mądrze podsumujemy temat - warto tworzyć funkcje filtrujące/walidujące uploadowane obrazki, czy po prostu zadbać, aby w kodzie nie było wczytywania obrazków metodami include/require (zakładamy, że konfiguracja Apache jest wolna od takich kwiatków jak podał erix)?

Czytać umie?

Pyro tu chyba toczy się rozmowa pod tematem "Zabezpieczenie przed..." a nie "Jak wykorzystać File Inclusion..." Chociaż chętnie poczytam, co można zrobić ze stroną, gdy już wiemy, że na stronie są niepoprawnie wypluwane pliki graficznie (albo w inny sposób można wykonać własny kod PHP)...

No ale właśnie przez podatność na "File Inclusion" trzeba się zabezpieczyć przed tego typu kodami w obrazku... tak więc ma to duże znaczenie

PS. Uważam że ten temat powinnien zostać przyklejony z uwagi na bezpieczeństwo skryptów

Trzeba się zabezpieczać, a nie z góry planować minimalizowanie (często jedynie pozorne) strat.

1. Kod PHP czy JS w obrazie? Jak najbardziej może się znajdować i wcale nie oznacza to żadnego ataku. Ot może to być chociażby fragment opisu obrazu przedstawiającego zrzut ekranu.
2. Podatność na File Inclusion to naprawdę domena słabych skryptów, co więcej jeżeli już taka luka istnieje bardzo, bardzo często umożliwia ona wczytanie dowolnego, zdalnego zasobu, więc całe to filtrowanie szlag trafia.

Lepiej sprawdzić czy gdzieś nie ma możliwości wykonania takiego ataku, szczególnie, że wiadomo czego szukać, niż kombinować z mechanizmami praktycznie bezużytecznymi mogącymi w dodatku odrzucać część w pełni poprawnych plików.

Z tym to się częściowo zgodzę,bo lepiej wykluczyć możliwości wykonania takiego ataku,jak i wyeliminować ewentualne pliki ,które taki atak mogłyby przepuścić.

Myślisz, że tylko ty potrafisz dziwnie kombinować? No ok, w takim razie: "Zabezpieczenie przed wykorzystaniem File Inclusion".

Czekam na odpowiedź

Ciekawe czy takie wykrywanie i raportowanie działa, jak należy, może ktoś próbował? http://az.linux.pl/2011/09/wykrywanie-atakow-lfi-auditd.html

Nie dam sobie ręki uciąć, ale chyba zmniejszenie obrazka, powiedzmy zmiana jego jakości/rozdzielczości kopiuje tylko sam obraz, zostawiając komentarze i wszystko pozostałe w oryginale, który możemy później skasować. Nie jestem co do tego pewien, gdzieś mi się to o uszy obiło.

Problem z tymi obrazkami to w sumie mógłby być jedynie w przypadki IE (5 lub 6) tam jakiś bug istniał z tymi obrazkami, że IE nie sprawdzał w ogóle mime danego pliku, i od razu próbował go wyświetlić, w ten sposób można było robić xss, zamieszczając kod js, zamiast obrazka, powiedzmy na jakimś forum czy w jakichś komentarzach gdzie można by wyświetlić jakieś zewnętrzne grafiki.