Укрощение Интренет@

Таких символов довольно много и все они (что очень неприятно) специфичны для каждой функции. Например, у open опасны следующие символы и их комбинации:

• «>»,»>>» и «+>» открытие файла для записи, дозаписи и перезаписи соответственно

• «+<" открытие файла для записи и чтения

• «|» и «`» запуск программы

• «-» чтение со стандартного ввода

• «&» обращение к файловому дескриптору (handle)

• «..» и «/» – обращение к вышележащим каталогам

• «\0″ – задание конца строки

О возможности обращения к файлу по его дескриптору следует сказать особо. Пусть существует некоторый секретный файл (например, файл паролей или номеров кредитных карт), который открывается в начале работы программы, а затем на экран выводится содержимое файла, запрошенного пользователем, до закрытия секретного файла. Если злоумышленнику доступен исходный тест скрипта или хотя бы приблизительно известны манеры его разработчика, он сможет прочитать секретный файл с помощью самой программы, передав вместо имени его дескриптор! Достаточно воспользоваться клонированием «x&filehandle» или созданием псевдонимов «x&=filehandle», где «x» обозначает режим доступа – «<" для чтения и ">» для записи. Следующий пример как раз и демонстрирует эту уязвимость.

open (psw,»passwd») || die; #открытие файла паролей

#…некоторый код…

print «введите имя файла:» #запрос имени отображаемого файла

$filename=<>; chop $filename;

if ($filename eq «passwd») #проверка имени на корректность

{print «Hello,Hacker!\n»;die;}

open(f,$filename) || die; #вывод файла на экран

while()

{

print;

}

Если злоумышленник введет «<&=psw" или "<&psw", в окне собственного браузера он увидит содержимое файла паролей!

Аналогичным путем можно ознакомится и содержимым лексемы DATA, доступной через одноименный дескриптор и часто содержащей информацию, не для посторонних глаз. (Замечание: не все реализации Perl позволяют клонировать манипулятор DATA, и, в общем-то, они и не должны этого делать, но пренебрегать такой угрозой не стоит).

Много непонимания вызывает интерполяция строк, заключенных в двойные кавычки. Язык Perl может автоматически подставлять вместо имени переменной ее содержимое, а вместо имени функции – возвращенный ею результат. Последняя возможность считается особо опасной, т.к. на первый взгляд позволяет злоумышленнику вызывать любые команды Perl и даже выполнять внешние программы с помощью функций exec, eval и многих других. Практически все руководства по написанию скриптов настоятельно рекомендуют фильтровать символы «@», «$», «[]«, «{}», «()», и разработчики (даже опытные!) в большинстве своем послушно следуют этому требованию!

На самом деле никакой опасности нет – интерполяция строк выполняется только в текстах программ и никогда в значениях переменных. Наглядно продемонстрировать это утверждение позволяет следующий пример (предполагается, что во втором случае с клавиатуры вводится : «${\(print ‘>Hello’)}»; наклонным шрифтом выделен вывод программы на экран):

$filename=»${\(print ‘>Hello’)}»; $filename=<>;

print «$filename»; print «$filename»;

>Hello1 ${\(print ‘>Hello’)}

Замены имени функции на результат ее работы в пользовательском вводе не произошло! Независимо от того, заключена ли введенная строка в двойные кавычки или нет, она всегда отображается на экране такой, какая есть, без каких бы то ни было преобразований. Фильтровать символы интерполяции не нужно – их использование злоумышленником не возымеет никакого эффекта! Тем более, что «собака» является неотъемлемой частью адреса электронной почты и отказ от нее просто невозможен.

Так же напрасны опасения относительно обратной кавычки – «`». В документации по языку Perl сказано, что строка, заключенная в обратные кавычки, интерпретируется как команда операционной системы, которой она и передаются на выполнение. Да, это действительно так, но только по отношению к строкам текста программы, а не содержимому скалярных переменных. Т.е. конструкция «$a=`type /etc/passwd`;» занесет в переменную $a содержимое файла «/etc/passwd», но «$a=<>;» никогда не приведет к подобному результату – чтобы ни ввел пользователь, Поэтому, символ обратной кавычки никакой угрозы не несет и совершенно ни к чему его фильтровать.

Гораздо больше проблем связано с вызовом внешних программ, работающих с данными, введенными пользователем. Заведомо невозможно узнать — какие символы потенциально опасны, а какие нет. Большинство приложений помимо документированных функций имеют множество недокументированных особенностей или хуже того – ошибок реализации.

Никогда нельзя быть абсолютно уверенным, что ваш почтовый агент не воспримет вполне легальный адрес назначения как собственный ключ или управляющее сообщение.

Страниц: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142