Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Безопасность




Вообще говоря, cледует понимать, что использование механизма сессий не гарантирует полной безопасности системы. Для этого нужно принимать дополнительные меры. Обратим внимание на проблемы с безопасностью, которые могут возникнуть при работе с сессиями и, в частности, с теми программами, что мы написали.

Во-первых, опасно передавать туда-сюда пароль, его могут перехватить. Кроме того, мы зарегистрировали его как глобальную переменную сессии, значит, он сохранился в cookies на компьютере-клиенте. Это тоже плохо. И вообще, пароли и логины по-хорошему должны храниться в базе данных. Пусть информация о пользователях хранится в базе данных "test" (в таблице "users"), а мы имеем к ней доступ под логином my_user и паролем my_passwd.

Во-вторых, что делать, если кто-то написал скрипт подбора пароля для секретной страницы? В этом случае на страницу авторизации много раз должен стучаться какой-то посторонний скрипт. Поэтому нужно просто проверять, с нашего ли сайта пришел запрос на авторизацию, и если нет, то не пускать его дальше. Адрес страницы, с которой поступил запрос, можно получить с помощью глобальной переменной $_SERVER['HTTP_REFERER']). Хотя, конечно, если за взлом сайта взялись всерьез, то значение этой переменной тоже подменят (например, с помощью того же PHP). Тем не менее проверку ее значения можно считать одним из важнейших шагов на пути к обеспечению безопасности своего сайта.

Листинг 12.6. authorize.php (html, txt)

<?session_start(); // создаем новую сессию или // восстанавливаем текущую$conn = mysql_connect("localhost", "my_user","my_passwd"); // устанавливаем соединение с БДmysql_select_db("test"); // выбираем рабочую базу данных $SERVER_ROOT = "http://localhost/~nina/tasks/sessions/"; // где находятся наши скрипты /* с помощью регулярного выражения ^$SERVER_ROOT и функции eregi проверяем, начинается ли адрес ссылающегося скрипта, т.е. строка $_SERVER['HTTP_REFERER']) со строки $SERVER_ROOT (как у нас) */ if(eregi("^$SERVER_ROOT", $_SERVER['HTTP_REFERER'])){// если да, то делаем почти то же, что и// раньше, пароль регистрировать не будемif (!isset($_POST['go'])){ echo "<form method=POST > Login: <input type=text name=login> Password: <input type=password name=passwd> <input type=submit name=go value=Go> </form>";}else {/* запрос к базе данных: выбираем из таблицыusers login, который совпадает с переданнымпо запросу, причем пароль у него тоже долженсовпасть с введенным пользователем. Если этого нет, то считаем, что логин и пароль введены неверно */$sql = "SELECT login FROM users WHERE login='". $_POST['login']. "' AND passwd='". $_POST['passwd']. "'";$q = mysql_query($sql,$conn); // отправляем запрос к БД$n = mysql_num_rows($q); // число строк в ответе на запросif (!$n==0){ $_SESSION['user_login']=$_POST['login']; // регистрируем переменную login Header("Location: secret_info.php"); // перенаправляем на страницу secret_info.php }else echo "Неверный ввод, попробуйте еще раз<br>";}print_r($_SESSION); // выводим все переменные сессии}?>

 

Вроде бы первые две проблемы решены. Но есть еще одна. Что делать, если хакер просто допишет в строку запроса значение какой-нибудь глобальной переменной (например, логина)? Вообще это возможно, только если register_globals=On. Просто иначе мы используем для работы с глобальными переменными массив $_SESSION и с ним такие фокусы не проходят. Все же попробуем решить и эту проблему. Для этого нужно очистить строку запроса перед тем, как сравнивать значения параметров. То есть сначала сбросим значение $user_login. Потом данную переменную нужно опять зарегистрировать, но не как новую, а как уже существующую. Для этого знак доллара при регистрации НЕ опускается. Вот что получилось:

<?phpunset($user_login); // уничтожаем переменнуюsession_start(); // создаем новую сессию или // восстанавливаем текущуюsession_register($user_login); // регистрируем переменную // как уже существующуюif (!($user_login==pit)) // проверяем логин Header("Location: authorize.php"); // если ошибка, то перенаправляем // на страницу авторизации?><html><head><title>Secret info</title></head>... // здесь располагается // секретная информация:)</html>

Заключение

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





Поделиться с друзьями:


Дата добавления: 2014-01-06; Просмотров: 414; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.008 сек.