programmingSimilar presentations:
Сессии и Cookie. Безопасность WEB-приложений
1.
Курс«Программирование в
компьютерных сетях»
Лекция 9
Приходько Татьяна Александровна
доцент кафедры
Вычислительных технологий КубГУ
1
2. Лекция 9 Сессии и Cookie Безопасность WEB-приложений
Бекэнд - разработка3. Вспомним термины
«WEB-технологии. Сессии и cookie»Вспомним термины
Хостинг-провайдер (владелец серверов)
обслуживает и предоставляет клиентам серверы (отдельные машины),
которые содержат узлы (имеющие отдельные 1Р-адреса).
На узле располагаются хосты,
которые могут быть обычными (имеют отдельный 1Р-адрес) или
виртуальными (имеют один IP-адрес, но разные имена), и содержат
сайты (часть хоста),
хранящиеся как HTML-документы (файлы).
иногда доступные как статические страницы, а также
скрипты (программы, создающие страницы),
генерирующие динамические страницы.
На узле также работают службы (процессы на сервере),
доступные через порт (номер, идентифицирующий процесс на
узле).
Провайдер (владелец модемного пула или NAT) предоставляет
пользователям доступ в Интернет.
3
4. Термины
«WEB-технологии. Сессии и cookie»Термины
Хост
Хост — с точки зрения пользователя как будто то же,
что и узел. Оба понятия очень часто смешивают. Это
обусловлено тем, что любой узел является хостом. Но
хост — совсем не обязательно отдельный узел, если
это виртуальный хост.
Часто хост имеет собственное уникальное
доменное имя. Иногда хосты называют
серверами, что, вообще говоря, совершенно не
верно. Фактически все, что отличает хост от
узла — это то, что он может быть
виртуальным.
Итак: любой узел — хост, но не любой хост
— узел, и именно так мы будем понимать хост.
4
5. Термины
«WEB-технологии. Сессии и cookie»Термины
Виртуальный хост
Это хост, не имеющий уникального IP-адреса в Сети,
но, тем не менее, доступный указанием какого-нибудь
дополнительного адреса (например, его DNS-имени).
В последнее время количество виртуальных хостов в
Интернете постоянно возрастает, что связано с
повсеместным распространением протокола HTTP 1.1. С
точки зрения Web-браузера (вернее, с точки зрения
пользователя, который этим браузером пользуется)
виртуальный хост выглядит так же, как и обычный хост —
правда его нельзя адресовать по IP-адресу. К сожалению,
все еще существуют версии браузеров, не поддерживающие
протокол HTTP 1.1, которые, соответственно, не могут
быть использованы для обращения к таким ресурсам.
5
6. Термины
«WEB-технологии. Сессии и cookie»Термины
Виртуальный хост
Замечание
Понятие "виртуальный хост" не ограничивается
только службой Web.
Многие другие сервисы имеют свои понятия о
виртуальных хостах, совершенно не связанные с Web и
протоколом HTTP 11. Сервер sendmail службы SMTP
(Send Mail Transfer Protocol, протокол передачи
почты) также использует понятие "виртуальный хост",
но для него это лишь синоним главного, основного
хоста, на котором запущен сервер Например, если хост
syn.com является синонимом для microsoft.com, то
адрес e-mail [email protected] на самом деле означает
microsoft.com. Примечательно, что виртуальный хост и
в этом смысле не имеет уникального IP-адреса.
6
7. Термины
«WEB-технологии. Сессии и cookie»Термины
URL и URI
URI (Universal Resource Identifier, универсальный
идентификатор ресурса). Очень часто его смешивают с
понятием URL (вплоть до того, что это происходит даже
в официальной документации по стандартам HTTP).
Далее мы будем называть словом URL полный путь к
некоторой Web-странице вместе с параметрами, а под
словом URI будет пониматься его часть, расположенная
после имени (или IP-адреса) хоста и номера порта.
7
8. Сессии
«WEB-технологии. Сессии и cookie»Сессии
HTTP веб-сервер не поддерживает постоянного
соединения с клиентом, и каждый запрос
обрабатывается, как новый, безо всякой связи с
предыдущими.
То есть, нельзя ни отследить запросы от одного
и того же посетителя, ни сохранить для него
переменные между просмотрами отдельных страниц.
Вот для решения этих двух задач и были
изобретены сессии.
Собственно, сессии- это механизм, позволяющий
однозначно идентифицировать браузер и
создаваемый для этого браузера файл на сервере,
в котором хранятся переменные сеанса.
8
9. Сессии
«WEB-технологии. Сессии и cookie»Сессии
Пример
Есть две страницы одного сайта,
index.php и dothings.php:
index.php
<?php $a = "Меня задали на
index.php"; ?>
<html><body>
<?php echo $a; ?>
</body></html>
dothings.php
<html><body>
<?php echo $a; ?>
</body></html>
Если выполнить эти два скрипта, то на первой
странице мы увидим надпись "Меня задали на
index.php", а вторая страница будет пустой.
Разработчики web-сайтов, недолго думая, стали
использовать cookie для хранения глобальных
переменных на стороне клиента.
9
10. Сессии vs Cookie
«WEB-технологии. Сессии и cookie»Сессии vs Cookie
Процесс выглядел примерно так: пользователь
приходит на главную страницу сайта, делает
какие-то действия, и вся информация, связанная
с этим пользователем, которая может
потребоваться на других страницах сайта, будет
храниться у него в браузере в виде cookie. Этот
метод имеет довольно серьезные минусы, из-за
которых от PHP в своё время отвернулось немало
разработчиков.
Например, нам нужно авторизовать пользователя,
чтобы разрешить ему доступ к закрытым (или
принадлежащим только ему) разделам сайта.
Придется отправлять пользователю cookie,
который будет служит его последующим
идентификатором на сайте.
10
11.
«WEB-технологии. Сессии и cookie»Сессии vs Cookie
Такой подход становится очень громоздким и не
удобным, как только сайт начинает собирать
всё больше и больше сведений о поведении
пользователя, ведь всю информацию, посылаемую
пользователю, желательно кодировать, чтобы её
нельзя было подделать. Ещё совсем недавно
подделкой cookie можно было "уложить" не один
чат, а порой и пробраться в чужую почту. К
тому же есть ещё на свете люди, у которых
браузер cookie не поддерживает.
11
12.
«WEB-технологии. Сессии и cookie»Сессии vs Cookie
При использовании сессий вся информация хранится
не на стороне клиента, а на стороне сервера, и
потому лучше защищена от манипуляций
злоумышленников.
Да и работать с сессиями куда проще и удобнее,
так как все данные автоматически проходят через
алгоритмы криптографии модуля PHP.
В браузере клиента, лишь хранится уникальный
идентификатор номера сессии, либо в форме
cookie, либо в виде переменной в адресной строке
браузера, какой из двух способов использовать
для передачи идентификатора сессии между
страницами интерпретатор PHP выбирает сам. Это
на 100% безопасно, так как идентификатор сессии
уникален, и подделать его практически невозможно
(об этом чуть далее, в разделе о безопасности
12
сессий).
13.
«WEB-технологии. Сессии и cookie»Сессии
Любой скрипт, который будет использовать
переменные (данные) из сессий, должен
содержать следующую строчку:
session_start();
Эта команда говорит серверу, что данная
страница нуждается во всех переменных, которые
связаны с данным пользователем (браузером).
Сервер берёт эти переменные из файла и делает
их доступными. Очень важно открыть сессию до
того, как какие-либо данные будут посылаться
пользователю; на практике это значит, что
функцию session_start() желательно вызывать в
самом начале страницы. Иначе появятся ошибки:
Warning: Cannot send session cookie - headers already sent
Warning: Cannot send session cache limiter - headers already sent
13
Решение проблемы: http://phpfaq.ru/newbie/headers
14. Сессии
«WEB-технологии. Сессии и cookie»Сессии
Пример
Изменим две страницы одного сайта,
index.php и dothings.php:
<?php
// открываем сессию
session_start();
// задаём значение переменной
$_SESSION['a'] = "Меня задали
на index.php";
?>
<html>
<head><meta charset='utf-8'/>
</head>
<body>
Всё ОК. Сессию загрузили!
Пройдём, посмотрим что <a
href="dothings.php">там:</a>
</body>
</html>
dothings.php <?php
// открываем
сессию
session_start();
?>
<html>
<head><meta charset='utf-8'/>
</head>
<body>
<?php
echo $_SESSION['a'];
?>
</body>
</html>
14
15.
«WEB-технологии. Сессии и cookie»Сессии
Другие полезные функции и приемы для работы с
сессиями:
unset($_SESSION['a']) - сессия "забывает"
значение заданной сессионной переменной;
session_destroy() - сессия уничтожается
(например, если пользователь покинул систему,
нажав кнопку "выход");
session_set_cookie_params(int lifetime [, string
path [, string domain]]) - с помощью этой функции
можно установить, как долго будет "жить" сессия,
задав unix_timestamp определяющий время "смерти"
сессии. По умолчанию, сессия "живёт" до тех пор,
пока клиент не закроет окно браузера.
session_write_close() - запись переменных сессии
и закрытие ее. Это необходимо для открытия сайта
в новом окне, если страница выполняет длительную
обработку и заблокировала для вашего браузера
15
файл сессий.
16. Cookie
«WEB-технологии. Сессии и cookie»Cookie
Идентификаторы сессий обычно отправляются
браузеру через сессионный cookie и используются
для получения имеющихся данных сессии.
Отсутствие идентификатора сессии или
сессионного cookie сообщает PHP о том, что
необходимо создать новую сессию и сгенерировать
новый идентификатор сессии.
Клиент устанавливает
куки и делает новый
запрос серверу
Cookie могут храниться даже после закрытия браузера,
однако по умолчанию – до окончания сессии.
16
Если Cookie отключены, то авторизация не произойдет.
17. Cookie
«WEB-технологии. Сессии и cookie»Cookie
Cookies – расширение протокола HTTP,
предназначенное для того, чтобы сохранять
на стороне клиента (в браузере) значения
некоторых переменных сайта, выдаваемых
сервером, и передавать эти значения при
каждом последующем HTTP-запросе на этот
сайт.
17
18. Cookie (пример)
«WEB-технологии. Сессии и cookie»Cookie
(пример)
Предположим, нам нужно написать счетчик
посещения сайта. Нам нужно знать, какое число
посещений сайта осуществлялось каждым
конкретным посетителем.
Данную задачу можно решить двумя способами.
Первый из них заключается в ведении учета
IP-адресов пользователей. Для этого нужна база
данных всего из одной таблицы, примерная
структура которой такая:
IP-адрес
210.124.134.203
212.201.78.207
83.103.203.73
Число
посещений
7
14
3
18
19. Cookie (пример)
«WEB-технологии. Сессии и cookie»Cookie
(пример)
Когда пользователь заходит на сайт, нам нужно
определить его IP-адрес, найти в базе данных
информацию о его посещениях, увеличить счетчик и
вывести его в браузер посетителя. Написать обработчик
(скрипт) подобной процедуры несложно. Однако при
использовании такого метода у нас появляются проблемы
следующего характера:
Для каждого IP-адреса нужно вести учет в одной
таблице, которая может быть очень большой нерациональное использование процессорного времени
и дискового пространства;
У большинства домашних пользователей IP-адреса
являются динамическими. То есть, сегодня у него
адрес 212.218.78.124, а завтра - 212.218.78.137 велика вероятность идентифицировать одного
пользователя несколько раз.
19
20. Cookie (пример)
«WEB-технологии. Сессии и cookie»Cookie
(пример)
Можно использовать второй способ, который
намного легче в реализации и более эффективен.
Мы устанавливаем в Cookie переменную, которая
будет храниться на диске удаленного
пользователя.
Эта переменная и будет хранить информацию о
посещениях. Она будет считываться скриптом при
обращении посетителя к серверу. Выгода такого
метода идентификации очевидна.
Во-первых, нам не нужно хранить множество
ненужной информации об IP-адресах.
Во-вторых, нас не интересуют динамические IPадреса, поскольку данные о своих посещениях
хранятся конкретно у каждого посетителя
сайта.
20
21. Cookie
«WEB-технологии. Сессии и cookie»Cookie
12345.txt
12345.Txt
name: Vasya
passvord: ***
Сессия хранится на сервере,
Cookie хранятся на клиенте.
21
22.
«WEB-технологии. Сессии и cookie»Сессии & cookie
При создании сессии сервер генерирует уникальный
идентификатор (идентификатор сессии) и передает
клиенту, используя cookies с заданным именем (имя
сессии) либо через адреса всех гиперссылок на
странице.
На сервере создаётся файл или запись в базу данных,
соответствующая идентификатору сессии. В этот файл
(запись) сервер может сохранять произвольные значения,
называемые переменными сессии.
При повторном запросе клиента сервер берет ID сессии
из cookies или строчки адреса и ищет по нему
соответствующий файл или запись в базе данных,
считывает их и распаковывает в память, доступную из
веб-приложения.
Таким образом, аналогично cookies значения
переменных сессии, установленные ранее,
становятся доступны серверу при
22
последующих HTTP-запросах.
23. Cookie
«WEB-технологии. Сессии и cookie»Cookie
Cookies передаются в HTTP открытым текстом в
заголовке.
Пользователь может задать и изменить
произвольным образом cookies в браузере.
Злоумышленник может узнать cookie, получив
доступ к компьютеру или с помощью JavaScript.
Так как значения cookie передаются с каждым
http-запросом, то хранение в них большого
объема данных затруднительно.
23
24. Cookie
«WEB-технологии. Сессии и cookie»Cookie
Примеры использования cookies:
можно сохранять список товаров в корзине
интернет магазина для незарегистрированного
пользователя;
после 1-й отправки некоторой формы можно
сохранять значение её полей в cookies для того,
чтобы в последующем вывести этому пользователю
форму, заполненную его данными по умолчанию;
можно использовать для вывода информации об
ошибке при отправке формы и её обработке по
схеме POST-redirect-GET.
Cookie различных сайтов изолированы друг от
друга!
В каком виде они хранятся определяет браузер.
24
25. Cookie
«WEB-технологии. Сессии и cookie»Cookie
Функция для установки cookies в PHP:
setcookie ($name, $value, $expire, $path, $domain, $secure, $httponly);
Параметры:
– name – имя переменной в cookie;
– value – значение переменной в cookie;
– expire – количество секунд, которые должны пройти с начала эпохи unix
до того момента, когда cookies будут сброшены браузером (для удаления
cookies время следует указать в прошлом);
– path – локальный путь от корня сайта, который указывает при запросах, к
каким ресурсам с данного сайта передавать cookies;
– domain – маска поддоменов основного домена, на которые надо
передавать cookies, например, при указании .example.com данная
cookie будет передаваться на все поддомены домена example.com;
– secure – передавать cookies клиенту только по защищённым (https)
соединениям;
– httponly – переменная в cookie передается только по HTTP и
недоступна для просмотра и изменения в JavaScript.
25
26. Cookie
«WEB-технологии. Сессии и cookie»Cookie
Пример функции установки cookies в PHP:
<?php
// Устанавливаем Cookie до конца сессии:
SetCookie("Test","Value");
// Устанавливаем Cookie на один час после у
становки:
SetCookie("My_Cookie","Value",time()+3600);
if (SetCookie("Test","Value")) echo "<h3>Cookie успешно устано
влен!</h3>";
else echo "<h3>Cookie установить не удалось!</h3>";
?>
Cookies должны устанавливаться до первого вывода
информации в браузер. Поэтому желательно устанавливать
Cookies в самом начале скрипта. Cookies устанавливаются
с помощью определенного заголовка сервера, а если
скрипт выводит что-либо, то это означает, что
начинается тело документа. В результате Cookies не
будут установлены и может быть выведено предупреждение.
26
27. Cookie
«WEB-технологии. Сессии и cookie»Cookie
Чтение cookies в PHP:
Получить доступ к Cookies и их значениям достаточно
просто. Они хранятся в суперглобальных массивах и
$_COOKIE и $HTTP_COOKIE_VARS.
Доступ к значениям осуществляется по имени
установленных Cookies:
<?php
// Устанавливаем Cookie 'test' со значением 'Hel
setcookie("test","Hello",time()+3600);
// При следующем запросе скрипта вывод
echo @$_COOKIE['test'];
// Удаляем Cookie 'Test':
SetCookie("Test","");
?>
Можно установить массив Cookies,
используя квадратные скобки в именах
Cookies [], а затем прочитать массив
27
Cookies, обращаясь по индексу.
28. Сессии & cookie
«WEB-технологии. Сессии и cookie»Сессии & cookie
Преимущества и недостатки использования
сессии по сравнению с cookies:
в сессии, в отличие от cookies, можно хранить
неограниченный объем данных без дополнительной
нагрузки на канал связи;
значения переменных сессии не передаются по сети
открытым текстом;
значения переменных сессии не могут быть
изменены клиентом непосредственно;
сессии занимают место на сервере;
устаревшие сессии необходимо удалять на сервере;
28
29. Сессии & cookie
«WEB-технологии. Сессии и cookie»Сессии & cookie
Преимущества и недостатки использования
сессии по сравнению с cookies (продолжение):
нарушается принцип HTTP, по которому все запросы
должны содержать исчерпывающую информацию для их
обработки.
Состояние приложения хранится на сервере. Это
приводит к тому, что на высоконагруженных вебприложениях, разделённых по нескольким вебсерверам, приходится проектировать совместный
доступ серверов к хранилищу сессий;
зная идентификатор сессии, злоумышленник может
выполнить HTTP-запрос к ресурсам в контексте сессии
пользователя.
29
30. Сессии & cookie
«WEB-технологии. Сессии и cookie»Сессии & cookie
Методы идентификации сессии:
• Идентификатор сессии - это обычная переменная. По
умолчанию ее имя - PHPSESSID.
• Задача PHP отправить ее браузеру, чтобы тот вернул
ее со следующим запросом. Переменную можно
передать только двумя способами: в куках или
POST/GET запросом.
PHP может использовать оба варианта.
• За это отвечают две настройки в php.ini:
session.use_cookies - если равно 1, то PHP
передает идентификатор в куках, если 0 - то нет.
session.use_trans_sid если равно 1, то PHP
передает его, добавляя к URL и формам, если 0 - то
нет.
• Менять эти и другие параметры сессий
можно так же, как и другие настройки PHP
- в файле php.ini, а так же с помощью
команды ini_set() или в файлах настройки 30
веб-сервера.
31. Сессии & cookie
«WEB-технологии. Сессии и cookie»Сессии & cookie
Методы идентификации сессии:
• Если включена только первая, то при старте сессии
(при каждом вызове session_start()) клиенту
устанавливается кука. Браузер исправно при каждом
следующем запросе эту куку возвращает и PHP имеет
идентификатор сессии. Проблемы начинаются, если
браузер куки не возвращает. В этом случае, не
получая куки с идентификатором, PHP будет все
время стартовать новую сессию, и механизм
работать не будет.
• Передача через URL:
31
32. Сессии & cookie
«WEB-технологии. Сессии и cookie»Сессии & cookie
Методы идентификации сессии:
• По умолчанию в последних версиях PHP включены обе
опции. Как PHP поступает в этом случае? Кука
выставляется всегда. А ссылки автодополняются
только если РНР не обнаружил куку с идентификатором
сессии.
• Когда пользователь в первый раз за этот сеанс
заходит на сайт, ему ставится кука, и дополняются
ссылки. При следующем запросе,
• если куки поддерживаются, PHP видит куку и
перестает дополнять ссылки.
• Если куки не работают, то PHP продолжает
исправно добавлять ID к ссылкам, и сессия не
теряется.
Пользователи, у которых работают куки, увидят
длинную ссылку с ид только один раз.
32
33. Сессии & cookie
«WEB-технологии. Сессии и cookie»Сессии & cookie
Пример работы с сессией:
<?
session_start();
if (!isset($_SESSION['counter'])) $_SESSION['counter']=0;
echo "Вы обновили эту страницу ".$_SESSION['coun
echo "<br><a href=".$_SERVER['PHP_SELF'].">обновить";
?>
Мы проверяем, есть ли у нас в сессии переменная
counter, если нет, то создаем ее со значением 0,
а дальше выводим ее значение и увеличиваем на
единицу. Увеличенное значение запишется в
сессию, и при следующем вызове скрипта
переменная будет иметь значение 1, и так далее.
33
34. Сессии & cookie
«WEB-технологии. Сессии и cookie»Сессии & cookie
Методы защиты сессии:
1) привязка сессии к IP-адресу клиента: после начала
сессии проверяется, не сменился ли IP после выдачи ID
сессии, если сменился, то сессия уничтожается;
2) устаревание сессии:
• при создании сессии сохраняется дата её открытия;
• при каждом следующем запросе обновляется дата
использования сессии;
• если при запросе с момента последнего
использования прошло больше заданного количества
времени, то сессия уничтожается;
3) регенерация идентификатора сессии: при
каждом запросе меняется идентификатор
сессии на новую случайную
последовательность на сервере и передается
клиенту.
34
35. Сессии & cookie
«WEB-технологии. Сессии и cookie»Сессии & cookie
Методы защитысессию
сессии: и проверяем
//стартуем
авторизацию пользователя
session_start();
if (isset($_SESSION['authorization'])) {
//проверяем совпадение ip-адреса и
браузера
$isBrowserMatch = ($_SESSION['browser'] ===
$_SERVER['HTTP_USER_AGENT']); $isIpMatch = ($_SESSION['ip'] ===
$_SERVER['REMOTE_ADDR']);
if (!$isIpMatch || !$isBrowserMatch) {
//уничтожаем сессию.
echo 'Требуется повторная
аутентификация!';
session_destroy();
}
else { echo 'Добро пожаловать,
пользователь!';
}
35
36. Авторизация пользователя
«WEB-технологии. Сессии и cookie»Авторизация пользователя
Механизм авторизации пользователей в
системе с помощью сессий довольно хорош с
точки зрения безопасности.
Наш пример будет состоять из трёх файлов:
index.php, authorize.php и secretplace.php.
Файл index.php содержит форму, где
пользователь введёт свой логин и пароль.
Эта форма передаст данные файлу
authorize.php, который в случае успешной
авторизации допустит пользователя к файлу
secretplace.php, а в противном случае
выдаст сообщение об ошибке.
36
37. Авторизация пользователя
«WEB-технологии. Сессии и cookie»Авторизация пользователя
index.php
<html>
<head>
<title>Вводи пароль</title>
<meta charset="utf-8"/>
</head>
<body>
<form action="authorize.php" method="post">
Логин: <input type="text"
name="user_name"><br>
Пароль: <input type="password"
name="user_pass"><br>
<input type="submit" name="Submit">
</form>
</body>
</html>
37
38. Авторизация пользователя
«WEB-технологии. Сессии и cookie»Авторизация пользователя
authorize.php
<?
session_start();
// данные были отправлены формой?
if($_POST['Submit']){
// проверяем данные на правильность... в данном случае
// имя пользователя и пароль вписан прямо в код,
// целесообразней было бы проверить логин/пароль в базе
// данных и при совпадении дать доступ пользователю...
if(($_POST['user_name']=="cleo")&&($_POST['user_pass']=="password"))
{
// запоминаем имя пользователя
$_SESSION['logged_user'] = $_POST['user_name'];
// и переправляем его на <секретную> страницу...
header("Location: secretplace.php");
exit;
}
}
// если что-то было не так, то польз-ль получит сообщение об ошибке.
?>
38
39. Авторизация пользователя
«WEB-технологии. Сессии и cookie»Авторизация пользователя
authorize.php
(продолжение)
<html>
<head>
<title>Вводи пароль</title>
<meta charset="utf-8"/>
</head>
<body>
<p> Вы ввели неверный пароль! </p>
</body>
</html>
39
40. Авторизация пользователя
«WEB-технологии. Сессии и cookie»Авторизация пользователя
secretplace.php
<?php
//открываем сессию
session_start();
echo session_id();
/*
просто зайти на эту страницу нельзя... Если
имя пользователя не зарегистрировано, то
перенаправляем его на страницу index.php
для ввода логина и пароля... тут на самом деле
можно много чего сделать, например запомнить
IP пользователя, и после третьей попытки получить
доступ к файлам, его закрыть.
*/
if(!isset($_SESSION['logged_user'])){
header("Location: index.php");
exit;
}
?>
40
41. Авторизация пользователя
«WEB-технологии. Сессии и cookie»Авторизация пользователя
secretplace.php
echo session_id();
41
42. Авторизация пользователя
«WEB-технологии. Сессии и cookie»Авторизация пользователя
secretplace.php
echo
session_name();
42
43. Авторизация пользователя
«WEB-технологии. Сессии и cookie»Авторизация пользователя
secretplace.php
(продолжение)
<html>
<head>
<title>Вводи пароль</title>
<meta charset="utf-8"/>
</head>
<body>
<p>Привет, <?php echo $_SESSION['logged_user']; ?>, ты
на секретной странице!!! :)</p>
</body>
</html>
Программа работает не совсем корректно…
43
44. Практическое задание 1
«WEB-технологии. Сессии и cookie»Практическое задание 1
Программа авторизации работает не совсем
корректно.
Найдите ошибку и исправьте ее:
При некорректном вводе скрипт должен трижды
возвращать пользователя к форме авторизации, а
затем выдавать сообщение, что его попытки
авторизации исчерпаны на 10 минут.
44
45. Практическое задание 2
«WEB-технологии. Сессии и cookie»Практическое задание 2
Разработать PHP-программу "Тестирование студента
на знание языков программирования". Программа должна
работать по схеме, приведенной ниже: каждый ответ
студента сохраняется в сессии и формируется новая
страница с вопросом, результат тестирования
вычисляется в файле result.php.
45
46. Практическое задание 2
«WEB-технологии. Сессии и cookie»Практическое задание 2
Подсказка:
Вторая страница теста выглядит примерно так:
<?php
session_start();
$ansver1=$_POST['answer1'];
$_SESSION['answer1']= $ansver1;
?>
<p>Вопрос2:</p>
<p>5*5=</p>
<form action="test3.php" method="post">
<input type="text" name="answer2"/>
<input type="submit"/>
</form>
Кол-во вопросов в тесте не меньше 10.
Тематика вопросов – наш предмет –
"Программирование в КС"
46
47. Еще о вопросах безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»Еще о вопросах безопасности
WEB-приложений
Рассмотрим возможные точки взлома в программе
авторизации пользователя:
• Файл authorize.php - попытка подбора пароля с
помощью стороннего скрипта;
• Файл secretplace.php - попытка обмануть программу
путём вписывания значений переменной $logged_user в
адресной строке браузера, например так:
"http://www.autorithation.ru/secretplace.php?logged_
user=cleo"
Итак, в нашей программе явно видны две "дыры", одна
маленькая и не особо заметная, а вот вторая -огромная,
через которую большинство хакеров и лезет туда, куда
не надо.
47
48. Еще о вопросах безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»Еще о вопросах безопасности WEBприложений
Как "залатать" дыру номер 1?
Не будем писать тонны кода по блокировке IPадреса и т.п., а просто проверим, откуда приходит
запрос, а точнее с какой страницы пришёл запрос,
если это будет любая страница с нашего сайта, то
всё нормально, а во всех остальных случаях пускать
не будем. Подкорректируем файл authorize.php:
<?php
// открываем сессию session_start();
// полный путь к корневой директории где расположены скрипты
$SERVER_ROOT = "http://autorithation.ru";
// если пользователь пришёл с любой страницы нашего сайта
// то он вроде наш...
// Переменная $HTTP_REFERER всегда доступна по умолчанию
// и содержит полный адрес ссылающейся страницы...
// функция eregi() проверяет, начинается ли адрес
48
//ссылающейся страницы со значения в переменной $SERVER_ROOT
49. Еще о вопросах безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»Еще о вопросах безопасности
WEB-приложений
if(preg_match("/^$SERVER_ROOT/",$_SERVER['HTTP_REFERER']))
{
// данные были отправлены формой?
if($_POST['Submit']){ // далее все как раньше
if(($_POST['user_name']=="cleo")&&($_POST['user_pass']=="p
assword"))
{ // запоминаем имя пользователя
$_SESSION['logged_user'] = $_POST['user_name'];
// и переправляем его на <секретную> страницу...
header("Location: secretplace.php");
exit; }
} }
?>
<html><head><title>Вводи пароль</title>
<meta charset="utf-8"/>
</head>
<body><p> Вы ввели неверный пароль!</p>
49
</body></html>
50. Еще о вопросах безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»Еще о вопросах безопасности WEBприложений
Как избавиться от "дыры" номер 2?
• Предположим, у вас есть сайт, где каждый может
зарегистрироваться чтобы добавлять сообщения в
форум.
• Естественно, в форуме у некоторых пользователей
(админов, модераторов), возможностей больше чем у
других, они, например, могут удалять сообщения
других пользователей.
• Уровень доступа пользователя вы храните в сессии,
в переменной $user_status, где $user_status = 10
соответствует полному доступу к системе.
• Пришедшему на сайт злоумышленнику достаточно
зарегистрироваться штатным образом, а потом
дописать в адресной строке браузера
?user_status=10. Вот и завёлся у вас на форуме
новый админ!
50
51. Еще о вопросах безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»Еще о вопросах безопасности WEBприложений
В принципе, любую переменную скрипта можно задать
через адресную строку, просто дописав после полного
адреса к скрипту вопросительный знак и название
переменной с её значением. Исправим наш код, чтобы
этого избежать:
secretplace.php V2
?php
// убираем всё лишнее из адресной
строки
// функция unset() <освобождает>
переменную unset($_SESSION['logged_user']);
session_start();
/* просто зайти на эту страницу
нельзя... если имя пользователя не
зарегистрировано, */
if(!isset($_SESSION['logged_user']))
{ header("Location: index.php"); exit; }
?>
<html> <body> Привет, <?php echo $_SESSION['logged_user']; ?>, ты
на секретной странице! </body> </html>
51
52. Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»Вопросы безопасности WEB-приложений
Уязвимости приложений могут быть использованы
злоумышленниками и вредоносными программами для
• показа нежелательной рекламы (спама),
• несанкционированного доступа к данным,
• повреждения данных веб-приложения,
• установления контроля над сервером или клиентом с
последующим использованием их вычислительных и
сетевых ресурсов.
Примерно половина случаев уязвимости веб-приложений
связана с некорректной настройкой и администрированием
программного обеспечения, остальные являются следствием
ошибок в программном коде.
Для написания безопасных веб-приложений необходимо
понимать, какой код содержит уязвимости безопасности и
почему. Для этого необходимо понимание общих сценариев
основных атак на веб-приложения.
52
53. Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»Вопросы безопасности WEB-приложений
CROSS SITE SCRIPTING
Атака Cross Site Scripting (XSS) заключается в
передаче на сервер кода JavaScript, который в
результате уязвимости в механизме фильтрации данных
веб-приложения может попасть в браузер клиента и
выполниться в нём в контексте сессии пользователя на
данном сайте.
При этом, в случае доступности Cookies из
JavaScript, возможна передача приватных данных третьей
стороне, например, через GET-параметры при загрузке
ресурса с сервера третьей стороны.
Подобная уязвимость встречается чаще всех прочих.
XSS регулярно находят как на больших сайтах, таких как
социальная сеть Вконтакте или сервисы Google и
Яндекса, так и в маленьких веб-приложениях и системах
управления контентом.
53
54. Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»Вопросы безопасности WEB-приложений
CROSS SITE SCRIPTING
Рассмотрим пример. Предположим, на странице
с формой, в случае ошибки, делается редирект и
сообщение об ошибке передается через URL:
«/form.php?msg=Ошибка», страницу с формой и
сообщением об ошибке формирует такой PHP-код:
<?php
// Текст ошибки поступает извне и не фильтруется.
$message = $_GET["msg"];
// Далее он выводится пользователю в исходном виде.
print("При заполнении формы произошли ошибки: ");
print($message);
Злоумышленник может разместить в Интернете или
послать по почте ссылку такого вида:
http://example.com/form.php?msg=<script>Произв
ольный код</script>
54
55. Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»Вопросы безопасности WEB-приложений
CROSS SITE SCRIPTING
После перехода по ней в браузере пользователя
выполнится произвольный JavaScript-код, который может
привести к краже Cookies, изменению настроек браузера и
даже запуску вредоносного приложения или дополнения
браузера при наличии уязвимостей в самом браузере.
В приведенном примере уязвимости можно было бы
избежать, если перед выводом содержимое message
отфильтровать функцией strip_tags() или экранировать
функцией htmlspecialchars():
// Текст ошибки поступает извне и фильтруется.
$message = strip_tags($_GET[’msg’]);
// Далее он выводится пользователю в исходном виде.
print(’При заполнении формы произошли ошибки: ’);
print($message);
55
strip_tags() — Удаляет HTML и PHP-теги из строки
56. Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»Вопросы безопасности WEB-приложений
CROSS SITE SCRIPTING
В данном примере содержится еще одна уязвимость –
раскрытия информации. Нежелательно сообщать всем о
работе PHP на сервере. Кроме того, идея передавать
сообщение таким образом крайне неудачна. Необходимо
ввести код ошибки и передавать код через URL, Cookies
или сессию.
Рассмотренную в примере уязвимость иногда называют
пассивной XSS, так как нефильтруемые перед выводом
данные не сохраняются на сервере, а выводятся
непосредственно из параметров запроса. В случае
активной XSS данные с вредоносным скриптом сохраняются
на сервере и выводятся пользователям или администратору
сайта при просмотре некоторой страницы.
56
57. Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»Вопросы безопасности WEB-приложений
CROSS SITE SCRIPTING
Для предотвращения уязвимостей к XSS и некоторым
другим атакам следует проверять все данные, поступившие
извне, на соответствие формату и очищать эти данные
непосредственно перед выдачей клиентам путем удаления
из данных небезопасных элементов (фильтрации) или же их
преобразования к безопасным эквивалентам (экранирования
и приведения типов).
Для этого существуют следующие способы:
Для проверки формата строк используют регулярные
выражения например, функцию preg_match() в PHP.
Исключение всех тегов или замена спецсимволов на
соответствующие HTML-коды для предотвращения
выполнения JavaScript на стороне клиента (функции
strip_tags() или htmlspecialchars() соответственно.)
Числовые данные перед выводом можно явно привести к
числовому типу, например, вызовом функции intval()57в
PHP.
58. Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»Вопросы безопасности WEB-приложений
SQL-INJECTION
Атака заключается в подстановке специальных значений
в параметры, поступающие в SQL-запросы веб-приложения.
Уязвимое к таким атакам приложение не делает должной
проверки на формат и экранирования кавычек и
спецсимволов в этих данных. В результате такой атаки
третья сторона может получить несанкционированный
доступ к данным, повредить данные.
Пример. Пусть во время авторизации пользователя на
сайте делается такой запрос к базе данных:
/ /Логин и пароль поступают извне и не экранируются.
$login = $_POST[’login’];
$password = $_POST[’pass’];
$query = "SELECT * FROM users WHERE login = ’" . $login . "’
AND pass = ’" . $pass . "’";
58
$result = mysql_query($query);
59. Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»Вопросы безопасности WEB-приложений
SQL-INJECTION
/ /Логин и пароль поступают извне и не экранируются.
$login = $_POST[’login’];
$password = $_POST[’pass’];
$query = "SELECT * FROM users WHERE login = ’" . $login . "’
AND pass = ’" . $pass . "’";
$result = mysql_query($query);
Если пользователь введет в качестве логина user’, то
закрывающая кавычка вызовет ошибку. Добавив после кавычки
нехитрую строку, можно видоизменить запрос так, что он выберет
из базы некоторого пользователя, даже если пароль указан
неверно.
Для устранения уязвимости следует экранировать кавычки
функцией mysql_real_escape_string():
// Логин и пароль экранируются.
$login = mysql_real_escape_string($_POST[’login’]);
$password = mysql_real_escape_string($_POST[’pass’]);
59
60. Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»Вопросы безопасности WEB-приложений
SQL-INJECTION
В данном примере имеется ещё одна серьезная
ошибка – хранение пароля в базе данных открытым
текстом. На практике хранят хэши паролей, например
с использованием функции md5() в PHP, сами пароли
не хранятся нигде, а при необходимости напоминания
пароля генерируют новый случайный пароль.
Для предотвращения уязвимостей к SQL-Injection атакам необходимо
проверять на соответствие формату и экранировать кавычки и
спецсимволы в поступающих от пользователя данных перед
использованием их в SQL-запросе, использовать подготовленные
запросы (Prepared Statements) при запросах к СУБД, применять
библиотеки абстракций, обеспечивающие безопасность при работе с СУБД.
60
61. Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»Вопросы безопасности WEB-приложений
CROSS SITE REQUEST FORGERY
Это атака на веб-приложение с помощью другого вебсайта с целью выполнить некоторый запрос к ресурсам в
контексте сессии авторизованного пользователя. Для
этого авторизованный пользователь должен загрузить
уязвимую страницу с формой с сайта третьей стороны
или со взломанного сайта и отправить форму методом
POST на атакуемый сайт или загрузить ресурс с
атакуемого сайта методом GET. Такой запрос, очевидно,
будет выполнен в контексте сессии пользователя
на атакуемом сайте и может привести к раскрытию
данных или потере данных.
61
62. Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»Вопросы безопасности WEB-приложений
CROSS SITE REQUEST FORGERY
Для защиты выполняется проверка подлинности формы
заключается в том, что когда на сервер приходят данные
методом POST, веб-приложение проверяет, действительно
ли они присланы нашей формой, которую веб-приложение
выдало этому пользователю ранее, либо эти данные
просто пытаются казаться таковыми.
Для этого в форму добавляется скрытое поле со
случайно генерируемой строкой (токеном), который
сохраняется на сервере с привязкой к сессии
пользователя, данные формы приходят вместе с токеном и
перед их принятием проверяется наличие токена в списке
выданных ранее.
Токе также может являться хэшем некоторых данных в
сессии пользователя и не храниться на сервере явно.
Подобный механизм проверки подлинности форм реализован
в большинстве развитых фреймворков для создания веб62
приложений и систем управления контентом.
63. Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»Вопросы безопасности WEB-приложений
UPLOAD-УЯЗВИМОСТИ
В случае когда веб-приложение предоставляет
пользователям возможность загрузить на сервер файл,
неправильная обработка загрузки может привести к
возможности закачки и исполнения на сервере
вредоносного скрипта.
Для исключения Upload-уязвимостей следует
проверять расширение загружаемых файлов по белому
списку допустимых расширений, помещать загружаемые
файлы в каталоги, из которых запрещено выполнение
скриптов веб-сервером и следование по символическим
ссылкам при поиске файлов и обработчиков вебзапросов.
63
64. Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»Вопросы безопасности WEB-приложений
УТЕЧКА ИНФОРМАЦИИ
В этот пункт попадают десятки уязвимостей,
связанных с раскрытием данных и технических деталей
реализации из-за некорректной реализации и
настройки веб-приложений. По частоте встречаемости
эти уязвимости уступают только уязвимостям к XSSатакам.
Сообщения об ошибках при обработке некорректных
запросов могут приводить к утечке важной
информации. После запуска веб-приложения необходимо
отключить отображение ошибок и настроить их
логирование.
Комментарии в JavaScript и HTML-коде
могут привести к раскрытию важных данных.
Их следует автоматически удалять из кода
перед выдачей клиентам.
64
65. Список использованной литературы
«WEB-технологии. Протокол HTTP»Список использованной литературы
1. HTTP протокол.
http://lectureskpd.readthedocs.io/kpd/3.http.html
2. Основа www: протокол HTTP. http://www.4stud.info/webprogramming/protocol-http.html
3. Введение в клиент-серверные технологии Веб. Протокол
HTTP.
https://www.intuit.ru/studies/courses/485/341/lecture/8182
65