При всех последующих запусках, сервер будет выводить приветствия на экран, увеличивающиеся в количестве с каждой итерацией.
Отсутствие фильтрации переменной “$0” и имен файлов может привести к перезаписи программного кода или HTML документа, расположенного на сервере.
Другая распространенная ошибка заключается в задании режима открытия файла по умолчанию. Используя тот факт, что функция “open”, интерпретирует первые символы имени файла, как режим доступа, появляется возможность открыть файл на запись! Для этого достаточно указать угловую скобку “»” перед именем файла.
Например, скрипт, приведенный ниже, на первый взгляд предназначается для чтения файлов:
На самом же деле, конструкция типа “»filename” способна уничтожить содержимое файла “filename”, что никак не входит в планы разработчика скрипта. Поэтому, рекомендуется явно задавать режим открытия, закрывая лазейку злоумышленнику. Правильное открытие файла для последующего чтения из него должно выглядеть приблизительно так: “open(F,”«$file”)”. Но отсюда вовсе не следует, что конструкция “open(F, “»$file”)”, открывающая файл для записи, то же окажется правильной! Если переменной “$filename” присвоить значение “» file”, в результате получится “open(F, “» file”)” и файл окажется открыт для дозаписи, что в корне меняет дело. В некоторых случаях такой трюк позволяет обойти лимиты на ограничение объема и забить мусором все доступное дисковое пространство или закачать на сервер файл свыше допустимого размера.
Еще одна распространенная ошибка связана с особенностью обработки символа “-“. Будучи переданным в качестве имени файла, он трактуется как “STDIN” (стандартный ввод) при чтении и “STDOUT” (стандартный вывод) при записи.
При использовании стандартных скриптов рекомендуется изменять имена всех файлов, особенно содержащих секретную информацию. В совокупности с правильной фильтрацией ввода, отсекающей все попытки просмотра содержимого директории, это в значительной степени снижает вероятность успешной атаки.
Но злоумышленнику вовсе не обязательно знать имя файла. Достаточно воспользоваться… клонированием файловых манипуляторов! Такой прием продемонстрирован в примере, приведенном ниже (на диске, прилагаемом к книге, он находится в файле “/SRC/cpyfh.pl”):
Если владельцем [299] (не разработчиком!) некой программы имя секретного файла (например, “passwd”) изменено до неузнаваемости, то вне зависимости от распространенности скрипта, злоумышленник, прежде чем сможет получить доступ к секретному файлу будет вынужден узнать его имя. Если нет возможности просмотреть исходный текст модифицированного скрипта, то для успешной атаки злоумышленнику потребуется не только получить доступ к хранящимся на сервере файлам, но и последовательно перебрать всех их один за другим, пока не встретится искомый.
Поэтому, при использовании общедоступных скриптов настоятельно рекомендуется изменять имена всех файлов, представляющих интерес для злоумышленника. Но в некоторых случаях такой прием оказывается бессилен предотвратить атаку, если разработчик допустит ошибку, в результате которой станет возможно клонирование файлового манипулятора, связанного с секретным файлом.
Например, в приведенном выше примере, секретный файл открывается в одной ветке программы, а где-то совершенно в другом месте присутствует код, выводящий на экран содержимое файла, указанного пользователем. Для предотвращения атаки выполняется проверка введенной пользователем строки на соответствие с именем секретного файла, и если злоумышленник решит действовать «в лоб», ничего не получится:
· GET /cgi-bin/cpyfh.pl?passwd
· Goodby, Hacker!
Однако если вместо имени файла ввести конструкцию “ amp;AH”, на экране появится содержимое секретного файла, что и продемонстрировано в примере, приведенном ниже:
· GET /cgi-bin/cpyfh.pl? amp;AH
· Vasia:qwerty
· Petja:admin
· Super:toyta
· Dimon:daemon