Czas na drugą część (tak, to oznacza że była część pierwsza ;>) posta o getimagesize. Tym razem skupie się bardziej na tym jak getimagesize robi to do czego została stworzona - czyli jak odczytuje wielkość z poszczególnych formatów graficznych. Będzie również o tym dlaczego getimagesize nie powinno się używać do sprawdzania czy uploadowany plik faktycznie jest obrazkiem.

Najpierw drobne uzupełnienie dot. notice'ów generowanych przez getimagesize: w wersjach PHP poniżej 5.2.6 błędy odczytu były sygnalizowane warningami, dopiero od wersji 5.2.6 został obniżony poziom istotności komunikatów o błędach odczytu.

OK, a teraz krótka lista formatów obsługiwanych przez getimagesize (w kolejności losowej):
- GIF
- JPEG
- PNG
- SWF
- SWC (od 4.3.0, wymaga statycznie zlinkowanego zlib)
- PSD (od 4.0.6)
- BMP (od 4.0.6)
- TIFF (od 4.2.0)
- JPC (od 4.3.2)
- JP2 (od 4.3.2)
- JPX (od 4.3.2)
- JB2 (od 4.3.2)
- IFF (od 4.3.0)
- WBMP (od 4.3.2)
- XBM (od 4.3.2)
- ICO (od 5.3.0)

W tym oraz kilku kolejnych postach opiszę implementacje poszczególnych funkcji wyciągających wielkość obrazka z danego formatu. Dzisiaj zacznę od formatu GIF, by w kolejnych postach omówić JPEG, ICO. BMP i inne.
Głównym celem na którym się skupie będzie uzyskanie ciągu bajtów który będzie poprawnie przechodził przez getimagesize ale nie będzie poprawnym obrazkiem, oraz na stworzeniu obrazka który ma inne wymiary (w sensie: przeglądarki traktują go jako np. większy) niż getimagesize zwraca.

1. GIF

Obsługą formatu GIF zajmuje się funkcja php_handle_gif, jednak aby do niej dojść, trzeba najpierw poprawnie przejść przez funkcje php_getimagetype która musi zwrócić IMAGE_FILETYPE_GIF. Aby tak się stało, poniższy warunek musi zostać spełniony:

if (!memcmp(filetype, php_sig_gif, 3)) {
 return IMAGE_FILETYPE_GIF;

Gdzie php_sig_gif to po prostu ciąg "GIF". Tak że php_getimagetype mamy załatwione, czas na php_handle_gif:

static struct gfxinfo *php_handle_gif (php_stream * stream TSRMLS_DC)
{
 struct gfxinfo *result = NULL;
 unsigned char dim[5];

 if (php_stream_seek(stream, 3, SEEK_CUR)) (1)
   return NULL;

 if (php_stream_read(stream, dim, sizeof(dim)) != sizeof(dim)) (2)
   return NULL;

 result = (struct gfxinfo *) ecalloc(1, sizeof(struct gfxinfo));
 result->width    = (unsigned int)dim[0] | (((unsigned int)dim[1])<<8);
 result->height   = (unsigned int)dim[2] | (((unsigned int)dim[3])<<8);
 result->bits     = dim[4]&0x80 ? ((((unsigned int)dim[4])&0x07) + 1) : 0;
 result->channels = 3; /* allways */

 return result;
}

Jak widać funkcja ta jest wyjątkowo krótka (w porównaniu do pełnej obsługi formatu GIF), i na dobrą sprawę opiera się na odczycie najpierw 3ch bajtów (if (1), to resztka magic'a GIFa, który mówi o wersji formatu; wg. standardu powinno tu być 87a lub 89a, ale jak widać w przypadku tej funkcji nie jest to wymagane), a następnie kolejnych 5ciu (if (2)). Po tych dwóch operacjach pola width/height/bits/channels struktury result są ustawiane wg. wartości odczytanych za drugim razem (konkretniej rzecz biorąc za drugim razem odczytywany jest fragment struktury Logical Screen Descriptor). I tyle.
Wniosek jest następujący: w przypadku formatu GIF (jak i innych formatów, jak okaże się później) getimagesize idzie po linii najmniejszego oporu, prosto do celu, ignorując wszystko inne.

W żadnym więc wypadku funkcja getimagesize nie może zostać wykorzystana do walidacji formatu GIF (nic dziwnego, w końcu ta funkcja nie została do walidacji stworzona, mimo iż niektórzy programiści używają ją właśnie w tym celu).

Przykładowy ciąg przechodzący poprawnie przez getimagesize, a na pewno nie będący poprawnym obrazkiem to:

$data = "GIFxxx" . pack("vvC", 1024, 768, 0xff);
$a = getimagesize("data://text/plain;base64," . base64_encode($data));
var_dump($a);

Wynik działania:
array(7) {
 [0]=>
 int(1024)
 [1]=>
 int(768)
 [2]=>
 int(1)
 [3]=>
 string(25) "width="1024" height="768""
 ["bits"]=>
 int(8)
 ["channels"]=>
 int(3)
 ["mime"]=>
 string(9) "image/gif"
}

OK, a co z obrazkiem który miałby inną wielkość niż zwraca getimagesize?
W tym momencie musimy poznać odpowiedź na pytanie: na ile możemy nagiąć standard GIF tak aby przeglądarka X wyświetliła obrazek poprawnie? Odpowiedź zależy oczywiście od wyboru przeglądarki X.
Oczywiście jest też drugie pytanie: jak nagiąć standard tak aby plik GIF był widziany powiedzmy jako 10x10 dla getimagesize, ale powiedzmy 256x192 dla przeglądarki?

W przypadku GIF może się okazać to dość łatwe. Osoby znające format GIF wiedzą że składa się on z jednego logicznego obrazka (którego wielkość jest właśnie odczytywana przez getimagesize), oraz z dowolnej ilości prostokątnych obrazków które są nakładane (wg. zaleceń zawartych w strukturach Image Descriptor) na obraz logiczny. Co dla nas ważne, wielkość każdego obrazka zapisywana jest oddzielnie!

Stwórzmy więc (można to zrobić np. przerabiając GIF hexedytorem) GIF'a który będzie miał wpisane 10x10 w Logical Screen Descriptor i 256x192 w Image Descriptor. Przy odrobinie szczęścia niektóre przeglądarki przeskalują Logical Screen do wielkości największego obrazka.

By the way...
On 22nd Nov'24 we're running a webinar called "CVEs of SSH" – it's free, but requires sign up: https://hexarcana.ch/workshops/cves-of-ssh (Dan from HexArcana is the speaker).

Przykładowy GIF (drogi czytelniku: jeżeli obrazek wyświetla się 256x192, to znaczy że Twoja przeglądarka powiększa Logical Screen do największego Image'a):



(Obrazek oczywiście pochodzi z http://icanhascheezburger.com/ ;>)
Jak się okazuje (empirycznie) powyższy obrazek wyświetlany jest jako 256x192 przez Firefox'a, Operę oraz Google Chrome. Natomiast Konqueror obcina obrazek do 10x10, a IE odmawia jego wyświetlenia (rezerwując jednak prostokąt wielkości 256x192 na potrzeby jego wyrenderowania).
Wynik getimagesize dla powyższego obrazka:

array(7) {
 [0]=>
 int(10)
 [1]=>
 int(10)
 [2]=>
 int(1)
 [3]=>
 string(22) "width="10" height="10""
 ["bits"]=>
 int(8)
 ["channels"]=>
 int(3)
 ["mime"]=>
 string(9) "image/gif"
}

I to by było na tyle...

P.S. Uprzedzając pytanie: taaak, sporo skryptów PHP korzysta z getimagesize żeby sprawdzić czy obrazek wrzucany przez user'a nie jest aby za duży. Guess they don't work too well, now do they?