Тысячи системных администраторов ежедневно читают security рассылки, пропатчивают свою систему от и до... Используют Файрволы. А из - за какого то скрипта гостевой книги, чата, форума, наконец, счетчика посещений вся защита внезапно рухнет. Одним из наиболее распространенных языков программирования, на которых пишутся CGI сценарии, является Perl. В данной статье пойдет речь о написании безопасных Web приложений на Perl. Основным методом раскрытия информации через недоработки в Perl сценарии является подмена входных данных. Взломщик пытается заставить скрипт работать не так, как предполагал программист во время написания данного скрипта. В том то и проблема Perl, что программы написанные на нем не являются компилируемыми. Хотя в этом есть свои плюсы. Нет компилятора Perl, есть интерпретатор Perl. То есть, в некоторых случаях, становится возможным заставить Perl - скрипт выполнить некоторый кусок сценария, который то же написан на Perl. Для начала я рассмотрю некоторые "опасные" функции, к которым следует относиться очень внимательно. Функция, выполняющие команды: system и т.д. Зачастую, при необходимости, в сценарии используются вышеописанные функции. Обычно данные функции используют для передачи какой то внешней программе определенных параметров и вывода готовых или обработанных результатов, для предоставления их пользователю. Пример: system('cat $file.txt'); В данной функции из переменной $file берется значение, равное названию файла без расширения, который далее следует вывести на экран. Программист в данном случае ограничил круг рассматриваемых фалов. Как видно функция прочитывает только текстовые файлы. Операции с файлами и каталогами: open, print, opendir и т.д. Синтаксис команды open таков: open(f, '$file.txt'); В данной функции так же из переменной $file берется значение, равное названию файла без расширения. При добавлении знака "+": open(f, '+$file.txt'), файл открывается на чтение. open(f, '>$file.txt') - файл открывается на запись. При добавлении прямой черты "|" происходит выполнение файла. open(f, '|/bin/ls') выполнит команду "ls". Получается, что и через функцию open и через system можно как читать файлы, так и выполнять команды. Методы управления функциями. 1) Изменение параметра , с целью видоизменения функции. Допустим, на сайте расположен скрипт board.pl, отвечающий за просмотр сообщений какого либо форума и скрипт post.pl, отвечающий за запись сообщений на страницы того же форума. Строка из скрипта board.pl: open(board,'$file'); # после чего происходит вывод страницы какого либо файла, являющегося разделом форума, на экран. Параметр "file" берется методом GET (то есть прямо из строки браузера). http://localhost/cgi-bin/board.pl?file=board1.html Что делает взломщик?! Он может предопределить положение и название файла, который выведется на экран. http://localhost/cgi-bin/board.pl?file=/etc/passwd - выведет на экран файл паролей. Взломщик может выполнить команду на сервере: http://localhost/cgi-bin/board.pl?file=|/bin/ls Взломщик использовал прямую черту для выполнения команды на сервере. И задал абсолютный путь к файлу паролей, для его просмотра. Чтобы исключить возможность просмотра не HTML фалов, программист видоизменил строку: open(board,'$file.html'); Теперь вроде бы взломщик не может не читать не HTML файлы, не выполнять команды, т.к. выполнять HTML файлы бессмысленно. Но на помощь взломщику придет null байт, а то есть "%00". Дело в том, что Perl считывает значение какой либо переменной до того, как наткнется на null байт. В итоге "%00" затрет ".txt". http://localhost/cgi-bin/board.pl?file=|/bin/ls%00 http://localhost/cgi-bin/board.pl?file=/etc/passwd Взломщик может и читать файлы сервера и выполнять команды. Видоизменим еще раз строку: open(board,'/$file.html'); Теперь программист предопределил директорию. Но при добавлении "../" перед именем файла, взломщик заставит искать файлы выше на директорию. http://localhost/cgi-bin/board.pl?file=../../../../../../../../etc/passwd И взломщик опять у цели. Если не предопределена директория, также можно добавлять атрибуты открытия файла. Допустим теперь, что скрипт открывает файл следующим образом: system('/bin/cat /$file.html'); Программист фильтрует параметры на символы "../". При открытии через системную функцию можно использовать обратный слэш. http://localhost/cgi-bin/board.pl?file=.\./.\./.\./etc/passwd Тот же результат. Но обратный слеш можно использовать только при вызове через shell функцию. Т.к. shell преобразует данные символы в символы "../". Так же, если в файле post.pl данного форума присутствуют те же ошибки, то взломщик сможет не только прочитывать, но и редактировать файлы на сервере. Предопределение атрибутов, с которыми открывается файл необходимы для того, чтобы взломщик не смог создать какой то фал на сервере и для других случаев, которые в данной статье рассматриваться не будут. Даже если файл открывается "на запись": open(f,'>/$file.txt'). Добавление первоначального атрибута на чтение даст некоторую защиту open(f,'+<$file.txt'). Взломщик сможет записать данные только в существующий файл. Еще одним опасным символов является символ конца строки "0x0a. существовал скрипт phf телефонной книги, идущий вместе с сервером Apache. Вроде бы, скрипт считывал данные о каком либо пользователе: nick, e-mail, phone и т.д. Но данная строка: http://localhost/cgi-bin/phf?Qalias= /bin/cat /etc/passwd выводила на экран файл паролей. 2) Изменение параметра , с целью отображения данного параметра. Данная проблема заключается в следующем. Какой то скрипт приветствует пользователя, называя последнего по нику или имени. Причем имя пользователя берет из входного параметра. После чего значение параметра отображается на экране. Если значение параметра не фильтруется, то становится возможным изменить HTML код, отображаемый на странице. Зачем это взломщику?! Для атаки на пользователя, который доверяет данному серверу и спокойно зайдет на любую ссылку, связанную с именем этого сервера. Используется для овладения системой пользователя или для компрометации сайта, на страницах которого присутствует данная ошибка. 3) Изменение параметра , с целью создания полноценного Perl - сценария. Допустим мы отправляем сообщение в вышеописанном форуме. Все параметры, связанные с именем файла, в который записывается сообщение, фильтруются на все необходимые символы. Сообщение отсылается в файл /cgi-bin/1.txt, а потом отображается на страницах данного форума. Допустим файл сообщений пустой. И в него записываются параметры: text (текст сообщения), name, e-mail. Взломщик пишет вместо текста сообщения Perl-сценарий. Добавляет в конец сообщения знак комментария и все остальные параметры, вносимые в файл сообщений игнорируются Perl-интерпретатором. А затем вызывает файл как http://localhost/cgi-bin/1.txt. Так как файл находится в папке /cgi-bin/, то файл вызовется, как скрипт и взломщик завладеет системой. 4) Изменение параметра, с целью передачи данного параметра другому приложению. Имеет место ошибка, возникающая при вводе какого то параметра в базу данных. Данный вид уязвимостей называется SQL-инъекция. Здесь важную роль играет одинарная кавычка. Т.к. попадая в логическое выражение сценария, управляющего базой данных кавычка дает возможность вывода результатов в файл. Иногда наличие одинарной кавычки в параметре для изменения SQL выражения не является необходимым. Это зависит от того, в каком виде Perl -сценарий предоставляет данный параметр другому приложению. Вообще, понятие SQL - Injection появилось с привязкой Perl к базе данных. 5) Изменение параметра, с целью создания ошибки в приложении. Зачем взломщику неработающее Perl - приложение?! Если приложение написано в лучшем стиле, то скрипт не просто откажется работать, а выдаст какую либо ошибку. Часто, подробные ответы об ошибках дают очень полезную информацию взломщику. Иногда это раскрытие абсолютного пути приложения, иногда другая даже более полезная информация. Данный вид атаки проводят и в том случае, когда параметр передается другому приложению. Здесь рассмотрены наиболее часто встречающиеся виды атак, направленные на Perl - приложения. Вы спросите: Как защититься от всего вышеописанного. Ниже рассмотрю принципы которых необходимо придерживаться, чтобы обеспечить себе относительно нормальную защиту. Да, именно относительно нормальную защиту, так как абсолютной защиты не существует. Как вы уже поняли, основная защита Perl - сценария сводиться к защите входящих параметров. 1) Заходя на какую либо страницу взломщик видит какие - либо параметры в адресной строке браузера. Грех не изменить. Защита? Замене метода GET на метод POST там, где это возможно. Это, возможно, отнимет больше времени у взломщика. А лучше, размещение методом GET параметров, которые не представляют опасности для Perl сценария, так же они должны быть защищены. А молодые псевдохакеры, еще "начинающие", могут помучаться над параметрами передающимися методом GET, забыть про метод POST и уйти с данного сайта в расстроенном виде. 2) Разделение параметров и шифрование параметров. Т.е. на странице есть три параметра, в сценарии они суммируются и полученный параметр уже подставляется в определенное выражение. При выходе данные параметры отображаются в зашифрованном виде. Взломщик долго будет на что каждый параметр влияет. 3) Задание имени входящего параметра. В сценарий входят два параметра. Пусть это будут дата и время созданной страницы. Может стоит запутать взломщика и поменять на странице название данных параметров, а в сценарии они будут подставляться как необходимо. Увидев в значении параметра "date" значение "123501" (которое соответствует значению времени 12:35:01), а в параметре "time" значение "140704" (которое соответствует дате 14.07.2004), взломщик будет запутан. Также стоит отметить, что не стоит задавать явно имя параметра. когда встречаешь ссылку "http://targethost/?file=photo", так и хочется зайти на нее и поменять параметр. А когда видишь ссылку "http://tergethost/?s=p". Кто знает за что отвечает параметр "S"?! Оказывается он открывает страницу "p.html". 4) Самое главное - фильтрация параметров на "опасные" символы. как было рассмотрено выше, основной способ заставить приложение работать не так - это ввод в параметр специальных символов, на которые может реагировать Perl - сценарий. Чаще всего используют фильтр на следующие символы: &;`'\"|*?~<>^()[]{}$\n\r. Если вы посмотрите внимательно, то увидите, что ни null байт, ни обратный слеш не присутствуют. Помимо данных символов должны фильтроваться все символы и группы символов, описанные в параграфе "Методы управления функциями". 5) Размещение фалов паролей и баз данных. Доступ к данным фалам должен быть запрещен. Если есть возможность, то файлы должны быть размещены не в директориях Web - сервера. Для Perl сценариев прописывается их полный путь, а вот взломщику просмотреть их будет более проблематично, чем если бы они находились в директориях сервера. 6) Конечно же ответы об ошибках. Они должны давать взломщику информации ровно столько, сколько он заслуживает. Не стоит упоминать в ответе о каких либо файлах или директориях, а так же о том, что может помочь взломщику. 7) Явная проверка параметров. Если Perl - сценарий работает всего с пятью - десятью файлами, название которых берется из какого то параметра. Может стоит прописать проверку перед открытием файла. Допустим: $a='photo.html'; $b='guest.html'; $c='program.html'; Вставьте проверку: если $file не равен ни $a, ни $b, ни $c, то выводится сообщение об ошибке и открытие не происходит. Это оградит вас от многих проблем. В заключении скажу: если вы используете какой то OpenSource, то не поленитесь, прочитайте исходники. Ни кто вас не посадит в тюрьму, если вы вставите несколько строк в чужой скрипт, который используете на своей системе. В данной статье описаны лишь некоторые аспекты защиты и взлома, при использовании Perl - сценариев, которые интересны автору. Данная статья не является пособием для взлома, а написана для того, что бы показать программистам и системным администраторам на ошибки, которые часто встречаются в распространенных Perl - сценариях. Заранее прошу извинить автора за неточности, которые возможно имеют место в данной статье. Автор: Dokk21
