Размещение кода PHP поможет определить цель сценария. В то время как, как указывало большинство комментаторов, этому может быть мягкое объяснение, я все же не исключаю, что будут происходить менее невинные махинации.
Доброкачественный случай : скрипт действительно предназначен для вывода изображения GIF, и вместо этого вы получили код из-за неправильной конфигурации сервера. Это может произойти, если:
- автор неправильно набрал команду в файле .htaccess, чтобы рассматривать все GIF-файлы или этот конкретный файл как PHP
- вебмастер переписал .htaccess с отсутствием указанных инструкций
- администратор сервера поместил
AllowOverride none
в свой httpd.conf, отключив все настройки пользовательского пространства
Я бы посмотрел на тип функций, используемых в коде. Предположительно, это файл GIF, и я ожидаю, что скрипт завершится инструкцией imagegif($img)
или около того, возможно, за ней последует imagedestroy($img)
. В этом случае сценарий, скорее всего, предназначен для вывода изображений GIF в браузер.
Злой случай : кто-то загрузил кучу хакерских вещей, маскируемых под GIF, ожидая, что позже запустит его, используя любой метод, который может дать ему доступ к командной строке: незащищенный eval()
, дыра в другом месте на сервере или даже уязвимость в абсолютно не связанном демоне, работающем на той же машине. Его преимуществом в этом случае будет то, что скрипт будет храниться в известном месте, полученном из корня сервера. Существуют сценарии, которые включают в себя полный файловый менеджер и наборы утилит в одном пакете - просто для того, чтобы создать хаос. Опять же, посмотрите на источник: если он начинается с шебанга (что-то вроде #!/bin/php /usr/htdocs/myfakeimagefile.gif
), он определенно должен запускаться из командной строки. Отсутствие shebang, однако, не означает, что его нельзя запускать как скрипт: если известно, где находится PHP, где находится скрипт и он может получить доступ к командной строке, возможно, все равно можно его запустить.