WEb практикум. Web'cepbep
 Скачать 4.76 Mb.
|
|
if ($UserName <> "") { print(" Ваше имя пользователя: "); print("$UserName"); } ?> Если загрузить эту форму в браузере, то переменная $UserName будет пустой, потому что еще не было передачи параметров и интерпретатор ничего не создавал. Если ввести имя пользователя и нажать клавишу С помощью форм можно передавать и скрытые параметры. Например, помимо имени пользователя вы хотите передавать еще какое-то значение, которое не должно быть видно в форме. Для этого вы можете захотеть создать невидимое поле ввода. Например, в следующей форме есть два поля ввода: UserName и Password, но второе поле не будет видимо, потому что у поля указан параметр type (тип), которому присвоено значение hidden (невидимый): Поле Password невидимо, но содержит значение. Таким образом можно передавать от сценария к сценарию определенные данные. Теперь после передачи параметров у сценария param.php будут две переменные $UserName и $Password с установленными значениями. Никогда не передавайте таким образом важные данные. Скрытые поля всегда привлекают внимание хакеров. Несмотря на то, что поле пароля невидимо на форме, любой браузер позволяет просмотреть исходный код HTML-формы. Например, в Internet Explorer для этого нужно выбрать меню View (Вид ) | Source (Источник). Любой хакер сможет увидеть этот параметр в исходном коде, а если надо, то и изменить. Для изменения исходный код сценария сохраняется на локальном диске пользователя, изменяется параметр (если надо, то изменяется поле action формы на полный URL) и выполняется запрос к web-серверу. Если вы не знаете, какие данные важные, а какие нет, то не используйте этот метод вообще. Через автоматическую регистрацию переменных можно повлиять на переменные, которые не должны были бы передаваться на сервер. Например: if ($isvalid == 1) { SaveData() ; } Если переменная $isvalid равна 1, то происходит сохранение данных в базу. Как переменная стала равна единице этому сценарию все равно. Если хакер загрузит URL: /scrupt.php?isvalid=1 то это приведет к автоматическому созданию переменной с именем isvalid, равной 1, что приведет к вызову метода SaveData. Таким образом можно влиять на логику выполнения программы и вызвать методы, которые могли быть запрещены для вызова без авторизации. Теперь поговорим подробнее о методах передачи параметров. Как мы уже знаем, их два — get и post. В обоих случаях интерпретатор создает переменные с такими же именами, но различия в методах есть. Метод GET Начнем с метода get. Все параметры, которые передаются сценарию, помещаются в глобальные переменные. Помимо этого, они помещаются в массив $http_get_vars. Чтобы не писать такое длинное имя массива, можно использовать имя $_get. Но и это еще не все. Пользователь может видеть параметры в строке URL. Например, после выполнения примера с передачей имени и пароля URL изменится на: http://192.168.77.1/param.php?UserName=Flenov&Password=qwerty. Здесь 192.168.77.1 — это адрес моего компьютера, на котором я тестирую примеры для этой книги. Иногда вы можете видеть имя, но с тем же успехом можно использовать и адрес, разницы тут нет. После адреса идет символ вопроса, а затем перечисляются параметры в виде имя= значение. Параметры разделены между собой символом амперсанда &. Как вы думаете, является ли этот метод безопасным? Совершенно нет. Хакеру достаточно просто будет изменить любой параметр вручную и подобрать его даже без изменения исходного кода формы для отправки параметров. Эта информация сохраняется и отображается в открытом виде во всех системах журналирования. Вторая проблема такого метода — открытость. Опять же, рассмотрим пример с паролем. Если пользователь ввел пароль и зашел в защищенную область web-сайта, то этот пароль будет находиться в строке URL. Любой мимо проходящий человек сможет без проблем увидеть эту строку и пароль. Никогда не передавайте важные данные методом get, в этом случае лучше использовать метод post. Но это не значит, что метод get не нужен совсем, просто к нему нужно подходить с особой осторожностью и проверять любые данные, которые получены этим способом. Когда нужно использовать get: когда вы точно уверены, что через параметры не передаются важные данные; когда это действительно удобно и/или необходимо. Когда может возникнуть необходимость? Простейший вариант: пользователь должен иметь возможность напрямую обратиться к web-странице без предварительного ввода параметров в отдельной форме. Допустим, мы хотим, чтобы при обращении к серверу он точно загружал определенный контент. Например, если пользователь передает на сайт номер новости, которую хочет увидеть, то она должна быть в URL, а если это информация, которая должна просто сохраниться в базе данных, то эти данные точно должны быть в POST -параметрах. Метод get часто используется в партнерских программах. Допустим, что вы зарегистрировались в качестве партнера магазина Amazon (www.amazon.com) и должны получать проценты от заказов товаров, сделанных по ссылке с вашего web-сайта. Как магазин узнает, что покупатель пришел именно по вашей ссылке? Самый простой пример — разместить на своем web-сайте ссылку на Amazon, в котором был бы параметр в формате get, идентифицирующий вас, например www.amazon.com?partner=flenov. В сценарии на web-сервере Amazon проверяется, если параметр partner содержит имя зарегистрированного партнера, то отчислять на его счет процент от заказанных товаров. (Внимание, это только пример, который никак не связан с реальным положением дела в работе с партнерами Amazon.) Метод GET слишком прост и позволяет хакеру легко использовать URL для поиска уязвимых мест в ваших сценариях. Чем еще страшны запросы get? Проблема кроется в поисковых системах, особенно в мощности поисковой системы Google. Нет, я не против такой мощи, потому что она необходима, но чтобы ваш web-сайт не оказался под угрозой, необходимо учитывать все возможные проблемы. Но хватит общих слов, давайте рассмотрим этот вопрос повнимательнее. Допустим, вы узнали, что в какой-либо системе управления web-сайтом появилась уязвимость. Что это за система? Существует множество платных и бесплатных готовых программ, написанных на PHP, Perl и других языках и позволяющих создать web-сайт без особых усилий. Такие системы могут включать в себя готовые реализации форумов, гостевых книг, лент новостей и т. д. Например, phpBB или ikonboard, которые очень широко распространены в интернете. Если в какой-нибудь из таких специальных программ найдена критическая уязвимость и о ней узнали хакеры, то все web-сайты в интернете, использующие ее, подвергаются опасности. Большинство администраторов не подписаны на новости и не обновляют используемые на web-сервере файлы сценариев, поэтому остается только найти нужный web-сайт и воспользоваться готовым решением для осуществления взлома. Как найти web-сайты или форумы, которые содержат уязвимость? Очень просто. Чаще всего сценарий жертвы можно определить по URL. Например, когда вы просматриваете на web-сайте www.sitename.ru раздел форума, использующего в качестве движка Invision Power Board, то строка адреса содержит следующий код: http://www.sitename.ru/index.php?showforum=4 Текст "index.php?showfomm=" будет встречаться на любом web-сайте, использующем для форума Invision Power Board. Чтобы найти web-сайты, содержащие в URL данный текст, нужно выполнить в поисковой системе Google следующий запрос: inurl:index.php?showforum Могут быть и другие программы, которые используют этот текст. Чтобы отбросить их, нужно еще добавить поиск какого-нибудь фрагмента из web-страниц. Например, по умолчанию внизу каждой web-страницы форума есть подпись "Powered by Invision Power Board(U)". Конечно же, администратор может изменить надпись, но в большинстве случаев ее не трогают. Именно такой текст можно добавить в строку поиска, и тогда результатом будут только web-страницы нужного нам форума. Попробуйте выполнить следующий запрос: Powered by Invision Power Board(U) inurl:index.php?showforum Вы увидите, сколько сайтов реализовано на этом сценарии. Теперь если появится уязвимость в Invision Power Board, то вы легко найдете жертву. Далеко не все администраторы успеют ликвидировать ошибки, а некоторые вообще не будут их исправлять. И все же метод get необходим. Большинство web-сайтов состоит не более чем из 10 файлов сценариев, которые отображают данные на web-странице, в зависимости от выбора пользователя. Например, взглянем на все тот же URL форума: http://www.sitename.ru/index.php?showforum=4. В данном случае вызывается сценарий index.php, а в качестве параметра передается showforum и число "4". Даже не зная исходного кода сценария, можно догадаться, что файл сценария должен показать на web-странице форум, который идентифицирован в базе данных под номером 4. В зависимости от номера форума web-страница будет выглядеть по-разному. А теперь представим, что номер форума будет передаваться с помощью метода post. В этом случае, какую бы web-страницу форума вы ни просматривали, URL будет выглядеть одинаково: http://www.sitename.ru/index.php. Значит, пользователь не сможет создать закладку на нужную web-страницу. Получается, что методом get нужно передавать и такие параметры, которые смогут однозначно идентифицировать web-страницу, но при этом нельзя нарушать правила, что данные должны быть безопасными и не должны содержать важных сведений. Сейчас принято вместо явных параметров после символа вопроса использовать неявные параметры по шаблону, которые разделяются в строке адреса слешами. Например один из адресов на моем сайте: https://www.flenov.info/books/show/linux- glazami-hakera. Если разбить его на составляющие, по слешу, то получается три параметра: books — это имя сценария на сайте, который нужно вызвать; show — команда, которую нужно выполнить в этом сценарии; linux-glazami-hakera — параметр, содержащий название книги "Linux глазами хакера". Именно ее содержимое я хочу отобразить. Это параметр со всеми вытекающими последствиями, потому что он подвержен тем же проблемам, что и любой другой параметр, который указывают после символа вопроса через знак равенства. Форматированный слешами адрес лучше с точки зрения продвижения сайта в поисковых системах, и здесь нет имен, которые бы упростили идентификацию движка. Сколько еще сайтов использует такой формат books/show? Кто угодно может так именовать адрес, и нет ничего уникального в именах. Метод POST Механизм использования метода post на сервере ничем не отличается от get. Достаточно только поменять имя метода формы, и ваш PHP-код будет работать без внесения дополнительных корректировок, если вы использовали для доступа к параметрам глобальные переменные, а не массив $http_get_vars (для post используется другой массив). Рассмотренный ранее пример, использующий метод get, при использовании метода post будет выглядеть следующим образом: При использовании метода posT в тело запроса попадают и все параметры в виде пар "имя=значение". Помимо этого, значения переменных и их имена попадают в массив $http_post_vars. Чтобы не писать такое длинное имя, можно использовать псевдоним $_post. Несмотря на то, что параметры не видны в строке URL, проблема не решается полностью. Допустим, что вы разрешили использовать глобальные переменные и используете их для доступа к параметрам, как показано в листинге 3.4. Сохраните этот код в файле с именем postparam.php. Листинг 3.4. Пример передачи параметров методом POST if ($UserName<>"") { print(" Ваше имя пользователя: "); print("$UserName") ; print(" Пароль: $Password"); } ?> В этом примере параметры передаются из формы методом post. Но несмотря на это, мы можем выполнить запрос следующего вида: http://192.168.77.1/ postparam.php?UserName=Flenov&Password=qwerty. То есть мы передаем параметры, как это делается при методе get, и при этом сценарий отработает верно. Почему? Проблема кроется в глобальных переменных, которые не разбираются, какой метод мы используем, и не зависят от него. В этом отношении использование массивов $http_post_vars и $http_get_vars более безопасно, потому что они привязаны к методу. Если бы мы обрабатывали параметры с помощью массива $http_post_vars, то попытка передать параметры методом get завершилась бы неудачей, потому что такие параметры попадают в другой массив $http_get_vars. Если использовать массивы $http_post_vars и $http_get_vars и полностью запретить автоматическую регистрацию переменных, то хакер не сможет повлиять на значение переменных, которые не передавались в качестве параметров и не хотели этого делать. В листинге 3.5 показано, как можно получить доступ к параметрам через массивы, а также запретить передачу параметров через строку URL, то есть методом get. Если массив $http_get_vars не пустой, то выполнение цикла прерывается с сообщением о неверном параметре. Листинг 3.5. Использование массивов для работы с параметрами if (count ($HTTP_GET_V.ARS) >0) { die("HeBepHbM параметр"); } if ($HTTP_POST_VARS["UserName"]<>"") { print(" Ваше имя пользователя: "); print($HTTP_POST_VARS["UserName"]) ; print(" Ваш пароль: "); print($HTTP_POST_VARS["Password"]); } ?> Значение кнопки также попадает в переменную. До этого мы всегда направляли данные web-серверу с помощью нажатия клавиши if ($sub="Go") { print (" Submitted : $Submit") ; Уязвимость Теперь посмотрим, как хакер может использовать автоматическую регистрацию переменных в своих корыстных целях. Допустим, что у нас есть сценарий, приведенный в листинге 3.6. Листинг 3.6. Уязвимый к автоматической регистрации переменных сценарий function checkparam($var) { $var=preg_replace(''/[Aa-z]/i", "", $var); return $var; } if (isset($_GET['file' ])) { $_GET['file'] = checkparam($_GET['file']); $_GET['dir'] = checkparam($_GET['dir']); } ?> |