Сессии и Cookie. Безопасность WEB-приложений

Август 1, 2022

Главная
Информатика
Сессии и Cookie. Безопасность WEB-приложений

Содержание

2. Лекция 9 Сессии и Cookie Безопасность WEB-приложений Бекэнд - разработка
3. Вспомним термины «WEB-технологии. Сессии и cookie» Хостинг-провайдер (владелец серверов) обслуживает и предоставляет клиентам серверы (отдельные машины),
4. Термины Хост Хост — с точки зрения пользователя как будто то же, что и узел. Оба
5. Термины Виртуальный хост Это хост, не имеющий уникального IP-адреса в Сети, но, тем не менее, доступный
6. Термины Виртуальный хост Замечание Понятие "виртуальный хост" не ограничивается только службой Web. Многие другие сервисы имеют
7. Термины URL и URI URI (Universal Resource Identifier, универсальный идентификатор ресурса). Очень часто его смешивают с
8. Сессии HTTP веб-сервер не поддерживает постоянного соединения с клиентом, и каждый запрос обрабатывается, как новый, безо
9. Сессии Если выполнить эти два скрипта, то на первой странице мы увидим надпись "Меня задали на
10. Сессии vs Cookie Процесс выглядел примерно так: пользователь приходит на главную страницу сайта, делает какие-то действия,
11. Такой подход становится очень громоздким и не удобным, как только сайт начинает собирать всё больше и
12. При использовании сессий вся информация хранится не на стороне клиента, а на стороне сервера, и потому
13. Сессии Любой скрипт, который будет использовать переменные (данные) из сессий, должен содержать следующую строчку: session_start(); Эта
14. Сессии // открываем сессию session_start(); // задаём значение переменной $_SESSION['a'] = "Меня задали на index.php"; ?>
15. Сессии Другие полезные функции и приемы для работы с сессиями: unset($_SESSION['a']) - сессия "забывает" значение заданной
16. Cookie Идентификаторы сессий обычно отправляются браузеру через сессионный cookie и используются для получения имеющихся данных сессии.
17. Cookie Cookies – расширение протокола HTTP, предназначенное для того, чтобы сохранять на стороне клиента (в браузере)
18. Cookie (пример) Предположим, нам нужно написать счетчик посещения сайта. Нам нужно знать, какое число посещений сайта
19. Cookie (пример) Когда пользователь заходит на сайт, нам нужно определить его IP-адрес, найти в базе данных
20. Cookie (пример) Можно использовать второй способ, который намного легче в реализации и более эффективен. Мы устанавливаем
21. Cookie Сессия хранится на сервере, Cookie хранятся на клиенте. 12345.txt 12345.Txt name: Vasya passvord: *** «WEB-технологии.
22. При создании сессии сервер генерирует уникальный идентификатор (идентификатор сессии) и передает клиенту, используя cookies с заданным
23. Cookie Cookies передаются в HTTP открытым текстом в заголовке. Пользователь может задать и изменить произвольным образом
24. Cookie Примеры использования cookies: можно сохранять список товаров в корзине интернет магазина для незарегистрированного пользователя; после
25. Cookie Функция для установки cookies в PHP: setcookie ($name, $value, $expire, $path, $domain, $secure, $httponly); Параметры:
26. Cookie Пример функции установки cookies в PHP: if (SetCookie("Test","Value")) echo " Cookie успешно установлен! "; else
27. Cookie Чтение cookies в PHP: Получить доступ к Cookies и их значениям достаточно просто. Они хранятся
28. Сессии & cookie Преимущества и недостатки использования сессии по сравнению с cookies: в сессии, в отличие
29. Сессии & cookie Преимущества и недостатки использования сессии по сравнению с cookies (продолжение): нарушается принцип HTTP,
30. Сессии & cookie Методы идентификации сессии: Идентификатор сессии - это обычная переменная. По умолчанию ее имя
31. Сессии & cookie Методы идентификации сессии: Если включена только первая, то при старте сессии (при каждом
32. Сессии & cookie Методы идентификации сессии: По умолчанию в последних версиях PHP включены обе опции. Как
33. Сессии & cookie Пример работы с сессией: обновить"; ?> Мы проверяем, есть ли у нас в
34. Сессии & cookie Методы защиты сессии: 1) привязка сессии к IP-адресу клиента: после начала сессии проверяется,
35. Сессии & cookie Методы защиты сессии: //стартуем сессию и проверяем авторизацию пользователя session_start(); if (isset($_SESSION['authorization'])) {
36. Авторизация пользователя Механизм авторизации пользователей в системе с помощью сессий довольно хорош с точки зрения безопасности.
37. Авторизация пользователя Вводи пароль Логин: Пароль: index.php «WEB-технологии. Сессии и cookie»
38. Авторизация пользователя authorize.php session_start(); // данные были отправлены формой? if($_POST['Submit']){ // проверяем данные на правильность... в
39. Авторизация пользователя authorize.php Вводи пароль Вы ввели неверный пароль! (продолжение) «WEB-технологии. Сессии и cookie»
40. Авторизация пользователя //открываем сессию session_start(); echo session_id(); /* просто зайти на эту страницу нельзя... Если имя
41. Авторизация пользователя echo session_id(); secretplace.php «WEB-технологии. Сессии и cookie»
42. Авторизация пользователя echo session_name(); secretplace.php «WEB-технологии. Сессии и cookie»
43. Авторизация пользователя (продолжение) Вводи пароль Привет, , ты на секретной странице!!! :) secretplace.php Программа работает не
44. Практическое задание 1 Программа авторизации работает не совсем корректно. Найдите ошибку и исправьте ее: При некорректном
45. Практическое задание 2 Разработать PHP-программу "Тестирование студента на знание языков программирования". Программа должна работать по схеме,
46. Практическое задание 2 Подсказка: Вторая страница теста выглядит примерно так: «WEB-технологии. Сессии и cookie» session_start(); $ansver1=$_POST['answer1'];
47. Еще о вопросах безопасности WEB-приложений «WEB-технологии. Протокол HTTP» Рассмотрим возможные точки взлома в программе авторизации пользователя:
48. Еще о вопросах безопасности WEB-приложений «WEB-технологии. Протокол HTTP» Как "залатать" дыру номер 1? Не будем писать
49. Еще о вопросах безопасности WEB-приложений «WEB-технологии. Протокол HTTP» if(preg_match("/^$SERVER_ROOT/",$_SERVER['HTTP_REFERER'])){ // данные были отправлены формой? if($_POST['Submit']){ //
50. Еще о вопросах безопасности WEB-приложений «WEB-технологии. Протокол HTTP» Как избавиться от "дыры" номер 2? Предположим, у
51. Еще о вопросах безопасности WEB-приложений «WEB-технологии. Протокол HTTP» В принципе, любую переменную скрипта можно задать через
52. Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» Уязвимости приложений могут быть использованы злоумышленниками и вредоносными программами для
53. Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» CROSS SITE SCRIPTING Атака Cross Site Scripting (XSS) заключается в
54. Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» CROSS SITE SCRIPTING Рассмотрим пример. Предположим, на странице с формой,
55. Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» CROSS SITE SCRIPTING После перехода по ней в браузере пользователя
56. Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» CROSS SITE SCRIPTING В данном примере содержится еще одна уязвимость
57. Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» CROSS SITE SCRIPTING Для предотвращения уязвимостей к XSS и некоторым
58. Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» SQL-INJECTION Атака заключается в подстановке специальных значений в параметры, поступающие
59. Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» SQL-INJECTION / /Логин и пароль поступают извне и не экранируются.
60. Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» SQL-INJECTION В данном примере имеется ещё одна серьезная ошибка –
61. Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» CROSS SITE REQUEST FORGERY Это атака на веб-приложение с помощью
62. Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» CROSS SITE REQUEST FORGERY Для защиты выполняется проверка подлинности формы
63. Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» UPLOAD-УЯЗВИМОСТИ В случае когда веб-приложение предоставляет пользователям возможность загрузить на
64. Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» УТЕЧКА ИНФОРМАЦИИ В этот пункт попадают десятки уязвимостей, связанных с
65. Список использованной литературы HTTP протокол. http://lectureskpd.readthedocs.io/kpd/3.http.html Основа www: протокол HTTP. http://www.4stud.info/web-programming/protocol-http.html Введение в клиент-серверные технологии Веб.
66. Объект XMLHttpRequest «WEB-технологии. Протокол HTTP» Объект XMLHttpRequest в современных браузерах позволяет после загрузки страницы из JavaScript
67. Объект XMLHttpRequest «WEB-технологии. Протокол HTTP» Создание объекта в браузерах: var xmlhttp = new XMLHttpRequest(); Возможности XMLHttpRequest:
68. Объект XMLHttpRequest «WEB-технологии. Протокол HTTP» Методы объекта (продолжение): getResponseHeader(name) – возвращает значение заголовка ответа с именем
69. Объект XMLHttpRequest «WEB-технологии. Протокол HTTP» Свойства объекта: onreadystatechange – событие, вызываемое при изменении состояния объекта при
70. Объект XMLHttpRequest «WEB-технологии. Протокол HTTP» Пример получения фрагмента сервера и вставка его в текущую страницу без
71. Объект XMLHttpRequest «WEB-технологии. Протокол HTTP» Пример отправки данных методом POST: xmlhttp.open("POST","ajax.php",true); xmlhttp.setRequestHeader("Content-type", "application/x-www-form-urlencoded"); xmlhttp.send("comment=Hello%20World!&name=Anonymous"); Пример обработчика
73. Скачать презентацию

Слайд 2

Лекция 9 Сессии и Cookie Безопасность WEB-приложений
Бекэнд - разработка

Слайд 3

Вспомним термины
«WEB-технологии. Сессии и cookie»
Хостинг-провайдер (владелец серверов)
обслуживает и предоставляет клиентам

серверы (отдельные машины), которые содержат узлы (имеющие отдельные 1Р-адреса).
На узле располагаются хосты,
которые могут быть обычными (имеют отдельный 1Р-адрес) или виртуальными (имеют один IP-адрес, но разные имена), и содержат сайты (часть хоста),
хранящиеся как HTML-документы (файлы).
иногда доступные как статические страницы, а также скрипты (программы, создающие страницы), генерирующие динамические страницы.
На узле также работают службы (процессы на сервере),
доступные через порт (номер, идентифицирующий процесс на узле).
Провайдер (владелец модемного пула или NAT) предоставляет пользователям доступ в Интернет.

Слайд 4

Термины
Хост
Хост — с точки зрения пользователя как будто то же, что

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

«WEB-технологии. Сессии и cookie»

Слайд 5

Термины
Виртуальный хост
Это хост, не имеющий уникального IP-адреса в Сети, но, тем

не менее, доступный указанием какого-нибудь дополнительного адреса (например, его DNS-имени).
В последнее время количество виртуальных хостов в Интернете постоянно возрастает, что связано с повсеместным распространением протокола HTTP 1.1. С точки зрения Web-браузера (вернее, с точки зрения пользователя, который этим браузером пользуется) виртуальный хост выглядит так же, как и обычный хост — правда его нельзя адресовать по IP-адресу. К сожалению, все еще существуют версии браузеров, не поддерживающие протокол HTTP 1.1, которые, соответственно, не могут быть использованы для обращения к таким ресурсам.

«WEB-технологии. Сессии и cookie»

Слайд 6

Термины
Виртуальный хост
Замечание
Понятие "виртуальный хост" не ограничивается только службой Web.
Многие другие

сервисы имеют свои понятия о виртуальных хостах, совершенно не связанные с Web и протоколом HTTP 11. Сервер sendmail службы SMTP (Send Mail Transfer Protocol, протокол передачи почты) также использует понятие "виртуальный хост", но для него это лишь синоним главного, основного хоста, на котором запущен сервер Например, если хост syn.com является синонимом для microsoft.com, то адрес e-mail my@syn.com на самом деле означает microsoft.com. Примечательно, что виртуальный хост и в этом смысле не имеет уникального IP-адреса.

«WEB-технологии. Сессии и cookie»

Слайд 7

Термины
URL и URI
URI (Universal Resource Identifier, универсальный идентификатор ресурса). Очень часто

его смешивают с понятием URL (вплоть до того, что это происходит даже в официальной документации по стандартам HTTP).
Далее мы будем называть словом URL полный путь к некоторой Web-странице вместе с параметрами, а под словом URI будет пониматься его часть, расположенная после имени (или IP-адреса) хоста и номера порта.

«WEB-технологии. Сессии и cookie»

Слайд 8

Сессии
HTTP веб-сервер не поддерживает постоянного соединения с клиентом, и каждый запрос

обрабатывается, как новый, безо всякой связи с предыдущими.
То есть, нельзя ни отследить запросы от одного и того же посетителя, ни сохранить для него переменные между просмотрами отдельных страниц. Вот для решения этих двух задач и были изобретены сессии.
Собственно, сессии- это механизм, позволяющий однозначно идентифицировать браузер и создаваемый для этого браузера файл на сервере, в котором хранятся переменные сеанса.

«WEB-технологии. Сессии и cookie»

Слайд 9

Сессии
Если выполнить эти два скрипта, то на первой странице мы увидим

надпись "Меня задали на index.php", а вторая страница будет пустой.
Разработчики web-сайтов, недолго думая, стали использовать cookie для хранения глобальных переменных на стороне клиента.

index.php

dothings.php

Пример

Есть две страницы одного сайта, index.php и dothings.php:

«WEB-технологии. Сессии и cookie»

Слайд 10

Сессии vs Cookie
Процесс выглядел примерно так: пользователь приходит на главную страницу

сайта, делает какие-то действия, и вся информация, связанная с этим пользователем, которая может потребоваться на других страницах сайта, будет храниться у него в браузере в виде cookie. Этот метод имеет довольно серьезные минусы, из-за которых от PHP в своё время отвернулось немало разработчиков.
Например, нам нужно авторизовать пользователя, чтобы разрешить ему доступ к закрытым (или принадлежащим только ему) разделам сайта. Придется отправлять пользователю cookie, который будет служит его последующим идентификатором на сайте.

«WEB-технологии. Сессии и cookie»

Слайд 11

Такой подход становится очень громоздким и не удобным, как только сайт

начинает собирать всё больше и больше сведений о поведении пользователя, ведь всю информацию, посылаемую пользователю, желательно кодировать, чтобы её нельзя было подделать. Ещё совсем недавно подделкой cookie можно было "уложить" не один чат, а порой и пробраться в чужую почту. К тому же есть ещё на свете люди, у которых браузер cookie не поддерживает.

Сессии vs Cookie

«WEB-технологии. Сессии и cookie»

Слайд 12

При использовании сессий вся информация хранится не на стороне клиента, а

на стороне сервера, и потому лучше защищена от манипуляций злоумышленников.
Да и работать с сессиями куда проще и удобнее, так как все данные автоматически проходят через алгоритмы криптографии модуля PHP.
В браузере клиента, лишь хранится уникальный идентификатор номера сессии, либо в форме cookie, либо в виде переменной в адресной строке браузера, какой из двух способов использовать для передачи идентификатора сессии между страницами интерпретатор PHP выбирает сам. Это на 100% безопасно, так как идентификатор сессии уникален, и подделать его практически невозможно (об этом чуть далее, в разделе о безопасности сессий).

Сессии vs Cookie

«WEB-технологии. Сессии и cookie»

Слайд 13

Сессии
Любой скрипт, который будет использовать переменные (данные) из сессий, должен содержать

следующую строчку:
session_start();
Эта команда говорит серверу, что данная страница нуждается во всех переменных, которые связаны с данным пользователем (браузером). Сервер берёт эти переменные из файла и делает их доступными. Очень важно открыть сессию до того, как какие-либо данные будут посылаться пользователю; на практике это значит, что функцию session_start() желательно вызывать в самом начале страницы. Иначе появятся ошибки:

Warning: Cannot send session cookie - headers already sent Warning: Cannot send session cache limiter - headers already sent

Решение проблемы: http://phpfaq.ru/newbie/headers

«WEB-технологии. Сессии и cookie»

Слайд 14

Сессии
// открываем сессию
session_start();
// задаём значение переменной
$_SESSION['a'] = "Меня задали на

index.php";
?>

Всё ОК. Сессию загрузили!
Пройдём, посмотрим что там:

dothings.php // открываем сессию
session_start();
?>

echo $_SESSION['a'];
?>

Пример

Изменим две страницы одного сайта, index.php и dothings.php:

«WEB-технологии. Сессии и cookie»

Слайд 15

Сессии
Другие полезные функции и приемы для работы с сессиями:
unset($_SESSION['a']) -

сессия "забывает" значение заданной сессионной переменной;
session_destroy() - сессия уничтожается (например, если пользователь покинул систему, нажав кнопку "выход");
session_set_cookie_params(int lifetime [, string path [, string domain]]) - с помощью этой функции можно установить, как долго будет "жить" сессия, задав unix_timestamp определяющий время "смерти" сессии. По умолчанию, сессия "живёт" до тех пор, пока клиент не закроет окно браузера.
session_write_close() - запись переменных сессии и закрытие ее. Это необходимо для открытия сайта в новом окне, если страница выполняет длительную обработку и заблокировала для вашего браузера файл сессий.

«WEB-технологии. Сессии и cookie»

Слайд 16

Cookie
Идентификаторы сессий обычно отправляются браузеру через сессионный cookie и используются для

получения имеющихся данных сессии.
Отсутствие идентификатора сессии или сессионного cookie сообщает PHP о том, что необходимо создать новую сессию и сгенерировать новый идентификатор сессии.

Клиент устанавливает куки и делает новый запрос серверу

Cookie могут храниться даже после закрытия браузера, однако по умолчанию – до окончания сессии. Если Cookie отключены, то авторизация не произойдет.

«WEB-технологии. Сессии и cookie»

Слайд 17

Cookie
Cookies – расширение протокола HTTP, предназначенное для того, чтобы сохранять на

стороне клиента (в браузере) значения некоторых переменных сайта, выдаваемых сервером, и передавать эти значения при каждом последующем HTTP-запросе на этот сайт.

«WEB-технологии. Сессии и cookie»

Слайд 18

Cookie (пример)
Предположим, нам нужно написать счетчик посещения сайта. Нам нужно знать,

какое число посещений сайта осуществлялось каждым конкретным посетителем.
Данную задачу можно решить двумя способами.
Первый из них заключается в ведении учета IP-адресов пользователей. Для этого нужна база данных всего из одной таблицы, примерная структура которой такая:

«WEB-технологии. Сессии и cookie»

Слайд 19

Cookie (пример)
Когда пользователь заходит на сайт, нам нужно определить его IP-адрес,

найти в базе данных информацию о его посещениях, увеличить счетчик и вывести его в браузер посетителя. Написать обработчик (скрипт) подобной процедуры несложно. Однако при использовании такого метода у нас появляются проблемы следующего характера:
Для каждого IP-адреса нужно вести учет в одной таблице, которая может быть очень большой - нерациональное использование процессорного времени и дискового пространства;
У большинства домашних пользователей IP-адреса являются динамическими. То есть, сегодня у него адрес 212.218.78.124, а завтра - 212.218.78.137 - велика вероятность идентифицировать одного пользователя несколько раз.

«WEB-технологии. Сессии и cookie»

Слайд 20

Cookie (пример)
Можно использовать второй способ, который намного легче в реализации и

более эффективен. Мы устанавливаем в Cookie переменную, которая будет храниться на диске удаленного пользователя.
Эта переменная и будет хранить информацию о посещениях. Она будет считываться скриптом при обращении посетителя к серверу. Выгода такого метода идентификации очевидна.
Во-первых, нам не нужно хранить множество ненужной информации об IP-адресах.
Во-вторых, нас не интересуют динамические IP-адреса, поскольку данные о своих посещениях хранятся конкретно у каждого посетителя сайта.

«WEB-технологии. Сессии и cookie»

Слайд 21

Cookie
Сессия хранится на сервере, Cookie хранятся на клиенте.
12345.txt
12345.Txt
name: Vasya
passvord: ***
«WEB-технологии. Сессии

и cookie»

Слайд 22

При создании сессии сервер генерирует уникальный идентификатор (идентификатор сессии) и передает

клиенту, используя cookies с заданным именем (имя сессии) либо через адреса всех гиперссылок на странице.
На сервере создаётся файл или запись в базу данных, соответствующая идентификатору сессии. В этот файл (запись) сервер может сохранять произвольные значения, называемые переменными сессии.
При повторном запросе клиента сервер берет ID сессии из cookies или строчки адреса и ищет по нему соответствующий файл или запись в базе данных, считывает их и распаковывает в память, доступную из веб-приложения.

Таким образом, аналогично cookies значения переменных сессии, установленные ранее, становятся доступны серверу при последующих HTTP-запросах.

Сессии & cookie

«WEB-технологии. Сессии и cookie»

Слайд 23

Cookie
Cookies передаются в HTTP открытым текстом в заголовке.
Пользователь может задать и

изменить произвольным образом cookies в браузере.
Злоумышленник может узнать cookie, получив доступ к компьютеру или с помощью JavaScript.
Так как значения cookie передаются с каждым http-запросом, то хранение в них большого объема данных затруднительно.

«WEB-технологии. Сессии и cookie»

Слайд 24

Cookie
Примеры использования cookies:
можно сохранять список товаров в корзине интернет магазина для

незарегистрированного пользователя;
после 1-й отправки некоторой формы можно сохранять значение её полей в cookies для того, чтобы в последующем вывести этому пользователю форму, заполненную его данными по умолчанию;
можно использовать для вывода информации об ошибке при отправке формы и её обработке по схеме POST-redirect-GET.

Cookie различных сайтов изолированы друг от друга!
В каком виде они хранятся определяет браузер.

«WEB-технологии. Сессии и cookie»

Слайд 25

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.

«WEB-технологии. Сессии и cookie»

Слайд 26

Cookie
Пример функции установки cookies в PHP:
if (SetCookie("Test","Value")) echo "
Cookie успешно установлен!
"; else echo "
Cookie установить не удалось!
";
?>
Cookies должны устанавливаться до первого

вывода информации в браузер. Поэтому желательно устанавливать Cookies в самом начале скрипта. Cookies устанавливаются с помощью определенного заголовка сервера, а если скрипт выводит что-либо, то это означает, что начинается тело документа. В результате Cookies не будут установлены и может быть выведено предупреждение.

«WEB-технологии. Сессии и cookie»

Слайд 27

Cookie
Чтение cookies в PHP:
Получить доступ к Cookies и их значениям достаточно

просто. Они хранятся в суперглобальных массивах и $_COOKIE и $HTTP_COOKIE_VARS.
Доступ к значениям осуществляется по имени установленных Cookies:

// Удаляем Cookie 'Test': SetCookie("Test","");
?>

Можно установить массив Cookies, используя квадратные скобки в именах Cookies [], а затем прочитать массив Cookies, обращаясь по индексу.

«WEB-технологии. Сессии и cookie»

Слайд 28

Сессии & cookie
Преимущества и недостатки использования
сессии по сравнению с cookies:
в

сессии, в отличие от cookies, можно хранить неограниченный объем данных без дополнительной нагрузки на канал связи;
значения переменных сессии не передаются по сети открытым текстом;
значения переменных сессии не могут быть изменены клиентом непосредственно;
сессии занимают место на сервере;
устаревшие сессии необходимо удалять на сервере;

«WEB-технологии. Сессии и cookie»

Слайд 29

Сессии & cookie
Преимущества и недостатки использования сессии по сравнению с cookies

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

«WEB-технологии. Сессии и cookie»

Слайд 30

Сессии & 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() или в файлах настройки веб-сервера.

«WEB-технологии. Сессии и cookie»

Слайд 31

Сессии & cookie
Методы идентификации сессии:
Если включена только первая, то при старте

сессии (при каждом вызове session_start()) клиенту устанавливается кука. Браузер исправно при каждом следующем запросе эту куку возвращает и PHP имеет идентификатор сессии. Проблемы начинаются, если браузер куки не возвращает. В этом случае, не получая куки с идентификатором, PHP будет все время стартовать новую сессию, и механизм работать не будет.
Передача через URL:

«WEB-технологии. Сессии и cookie»

Слайд 32

Сессии & cookie
Методы идентификации сессии:
По умолчанию в последних версиях PHP включены

обе опции. Как PHP поступает в этом случае? Кука выставляется всегда. А ссылки автодополняются только если РНР не обнаружил куку с идентификатором сессии.
Когда пользователь в первый раз за этот сеанс заходит на сайт, ему ставится кука, и дополняются ссылки. При следующем запросе,
если куки поддерживаются, PHP видит куку и перестает дополнять ссылки.
Если куки не работают, то PHP продолжает исправно добавлять ID к ссылкам, и сессия не теряется.
Пользователи, у которых работают куки, увидят длинную ссылку с ид только один раз.

«WEB-технологии. Сессии и cookie»

Слайд 33

Сессии & cookie
Пример работы с сессией:
обновить"; ?>
Мы проверяем, есть ли у

нас в сессии переменная counter, если нет, то создаем ее со значением 0, а дальше выводим ее значение и увеличиваем на единицу. Увеличенное значение запишется в сессию, и при следующем вызове скрипта переменная будет иметь значение 1, и так далее.

«WEB-технологии. Сессии и cookie»

Слайд 34

Сессии & cookie
Методы защиты сессии:
1) привязка сессии к IP-адресу клиента: после

начала сессии проверяется, не сменился ли IP после выдачи ID сессии, если сменился, то сессия уничтожается; 2) устаревание сессии:
при создании сессии сохраняется дата её открытия;
при каждом следующем запросе обновляется дата использования сессии;
если при запросе с момента последнего использования прошло больше заданного количества времени, то сессия уничтожается;
3) регенерация идентификатора сессии: при каждом запросе меняется идентификатор сессии на новую случайную последовательность на сервере и передается клиенту.

«WEB-технологии. Сессии и cookie»

Слайд 35

Сессии & 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 'Добро пожаловать, пользователь!';
}
}

«WEB-технологии. Сессии и cookie»

Слайд 36

Авторизация пользователя
Механизм авторизации пользователей в системе с помощью сессий довольно хорош

с точки зрения безопасности.
Наш пример будет состоять из трёх файлов: index.php, authorize.php и secretplace.php.
Файл index.php содержит форму, где пользователь введёт свой логин и пароль. Эта форма передаст данные файлу authorize.php, который в случае успешной авторизации допустит пользователя к файлу secretplace.php, а в противном случае выдаст сообщение об ошибке.

«WEB-технологии. Сессии и cookie»

Слайд 37

Авторизация пользователя

Вводи пароль

method="post">
Логин:
Пароль:

index.php

«WEB-технологии. Сессии и cookie»

Слайд 38

$Авторизация пользователя authorize.php session_start(); // данные были отправлены формой? if($_POST['Submit']){ //$

Авторизация пользователя
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;
}
}
// если что-то было не так, то польз-ль получит сообщение об ошибке.
?>

«WEB-технологии. Сессии и cookie»

Слайд 39

Авторизация пользователя
authorize.php

Вводи пароль

Вы ввели

неверный пароль!

(продолжение)

«WEB-технологии. Сессии и cookie»

Слайд 40

Авторизация пользователя
//открываем сессию
session_start();
echo session_id();
/*
просто зайти на эту страницу нельзя...

Если
имя пользователя не зарегистрировано, то
перенаправляем его на страницу index.php
для ввода логина и пароля... тут на самом деле
можно много чего сделать, например запомнить
IP пользователя, и после третьей попытки получить
доступ к файлам, его закрыть.
*/
if(!isset($_SESSION['logged_user'])){
header("Location: index.php");
exit;
}
?>

secretplace.php

«WEB-технологии. Сессии и cookie»

Слайд 41

Авторизация пользователя
echo session_id();
secretplace.php
«WEB-технологии. Сессии и cookie»

Слайд 42

Авторизация пользователя
echo session_name();
secretplace.php
«WEB-технологии. Сессии и cookie»

Слайд 43

Авторизация пользователя
(продолжение)

Вводи пароль

Привет,

echo $_SESSION['logged_user']; ?>, ты на секретной странице!!! :)

secretplace.php

Программа работает не совсем корректно…

«WEB-технологии. Сессии и cookie»

Слайд 44

Практическое задание 1
Программа авторизации работает не совсем корректно.
Найдите ошибку и исправьте

ее:
При некорректном вводе скрипт должен трижды возвращать пользователя к форме авторизации, а затем выдавать сообщение, что его попытки авторизации исчерпаны на 10 минут.

«WEB-технологии. Сессии и cookie»

Слайд 45

Практическое задание 2
Разработать PHP-программу "Тестирование студента на знание языков программирования". Программа

должна работать по схеме, приведенной ниже: каждый ответ студента сохраняется в сессии и формируется новая страница с вопросом, результат тестирования вычисляется в файле result.php.

«WEB-технологии. Сессии и cookie»

Слайд 46

Практическое задание 2
Подсказка:
Вторая страница теста выглядит примерно так:
«WEB-технологии. Сессии и cookie»

session_start();
$ansver1=$_POST['answer1'];
$_SESSION['answer1']= $ansver1;
?>

Вопрос2:

5*5=

Кол-во вопросов в тесте не меньше 10. Тематика вопросов – наш предмет –"Программирование в КС"

Слайд 47

Еще о вопросах безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
Рассмотрим возможные точки взлома

в программе авторизации пользователя:
Файл authorize.php - попытка подбора пароля с помощью стороннего скрипта;
Файл secretplace.php - попытка обмануть программу путём вписывания значений переменной $logged_user в адресной строке браузера, например так: "http://www.autorithation.ru/secretplace.php?logged_user=cleo"
Итак, в нашей программе явно видны две "дыры", одна маленькая и не особо заметная, а вот вторая -огромная, через которую большинство хакеров и лезет туда, куда не надо.

Слайд 48

Еще о вопросах безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
Как "залатать" дыру номер

1?
Не будем писать тонны кода по блокировке IP-адреса и т.п., а просто проверим, откуда приходит запрос, а точнее с какой страницы пришёл запрос, если это будет любая страница с нашего сайта, то всё нормально, а во всех остальных случаях пускать не будем. Подкорректируем файл authorize.php:

// открываем сессию session_start();
// полный путь к корневой директории где расположены скрипты $SERVER_ROOT = "http://autorithation.ru";
// если пользователь пришёл с любой страницы нашего сайта
// то он вроде наш...
// Переменная $HTTP_REFERER всегда доступна по умолчанию
// и содержит полный адрес ссылающейся страницы...
// функция eregi() проверяет, начинается ли адрес //ссылающейся страницы со значения в переменной $SERVER_ROOT

Слайд 49

$Еще о вопросах безопасности WEB-приложений «WEB-технологии. Протокол HTTP» if(preg_match("/^$SERVER_ROOT/",$_SERVER['HTTP_REFERER'])){ // данные$

Еще о вопросах безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
if(preg_match("/^$SERVER_ROOT/",$_SERVER['HTTP_REFERER'])){
// данные были

отправлены формой?
if($_POST['Submit']){ // далее все как раньше if(($_POST['user_name']=="cleo")&&($_POST['user_pass']=="password"))
{ // запоминаем имя пользователя $_SESSION['logged_user'] = $_POST['user_name'];
// и переправляем его на <секретную> страницу... header("Location: secretplace.php");
exit; }
} }
?>
Вводи пароль

Вы ввели неверный пароль!

Слайд 50

Еще о вопросах безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
Как избавиться от "дыры"

номер 2?
Предположим, у вас есть сайт, где каждый может зарегистрироваться чтобы добавлять сообщения в форум.
Естественно, в форуме у некоторых пользователей (админов, модераторов), возможностей больше чем у других, они, например, могут удалять сообщения других пользователей.
Уровень доступа пользователя вы храните в сессии, в переменной $user_status, где $user_status = 10 соответствует полному доступу к системе.
Пришедшему на сайт злоумышленнику достаточно зарегистрироваться штатным образом, а потом дописать в адресной строке браузера ?user_status=10. Вот и завёлся у вас на форуме новый админ!

Слайд 51

Еще о вопросах безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
В принципе, любую переменную

скрипта можно задать через адресную строку, просто дописав после полного адреса к скрипту вопросительный знак и название переменной с её значением. Исправим наш код, чтобы этого избежать:

?php
// убираем всё лишнее из адресной строки
// функция unset() <освобождает> переменную unset($_SESSION['logged_user']);
session_start();
/* просто зайти на эту страницу нельзя... если имя пользователя не зарегистрировано, */
if(!isset($_SESSION['logged_user']))
{ header("Location: index.php"); exit; }
?>
Привет, , ты на секретной странице!

secretplace.php V2

Слайд 52

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
Уязвимости приложений могут быть использованы злоумышленниками

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

Слайд 53

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
CROSS SITE SCRIPTING
Атака Cross Site Scripting

(XSS) заключается в передаче на сервер кода JavaScript, который в результате уязвимости в механизме фильтрации данных веб-приложения может попасть в браузер клиента и выполниться в нём в контексте сессии пользователя на данном сайте.
При этом, в случае доступности Cookies из JavaScript, возможна передача приватных данных третьей стороне, например, через GET-параметры при загрузке ресурса с сервера третьей стороны.
Подобная уязвимость встречается чаще всех прочих. XSS регулярно находят как на больших сайтах, таких как социальная сеть Вконтакте или сервисы Google и Яндекса, так и в маленьких веб-приложениях и системах управления контентом.

Слайд 54

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
CROSS SITE SCRIPTING
Рассмотрим пример. Предположим, на

странице с формой, в случае ошибки, делается редирект и сообщение об ошибке передается через URL: «/form.php?msg=Ошибка», страницу с формой и сообщением об ошибке формирует такой PHP-код:

$message = $_GET["msg"]; // Далее он выводится пользователю в исходном виде. print("При заполнении формы произошли ошибки: "); print($message);

Злоумышленник может разместить в Интернете или послать по почте ссылку такого вида:
http://example.com/form.php?msg=

Слайд 55

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
CROSS SITE SCRIPTING
После перехода по ней

в браузере пользователя выполнится произвольный JavaScript-код, который может привести к краже Cookies, изменению настроек браузера и даже запуску вредоносного приложения или дополнения браузера при наличии уязвимостей в самом браузере.
В приведенном примере уязвимости можно было бы избежать, если перед выводом содержимое message отфильтровать функцией strip_tags() или экранировать функцией htmlspecialchars():

// Текст ошибки поступает извне и фильтруется. $message = strip_tags($_GET[’msg’]); // Далее он выводится пользователю в исходном виде. print(’При заполнении формы произошли ошибки: ’); print($message);

strip_tags() — Удаляет HTML и PHP-теги из строки

Слайд 56

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
CROSS SITE SCRIPTING
В данном примере содержится

еще одна уязвимость – раскрытия информации. Нежелательно сообщать всем о работе PHP на сервере. Кроме того, идея передавать сообщение таким образом крайне неудачна. Необходимо ввести код ошибки и передавать код через URL, Cookies или сессию.
Рассмотренную в примере уязвимость иногда называют пассивной XSS, так как нефильтруемые перед выводом данные не сохраняются на сервере, а выводятся непосредственно из параметров запроса. В случае активной XSS данные с вредоносным скриптом сохраняются на сервере и выводятся пользователям или администратору сайта при просмотре некоторой страницы.

Слайд 57

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
CROSS SITE SCRIPTING
Для предотвращения уязвимостей к

XSS и некоторым другим атакам следует проверять все данные, поступившие извне, на соответствие формату и очищать эти данные непосредственно перед выдачей клиентам путем удаления из данных небезопасных элементов (фильтрации) или же их преобразования к безопасным эквивалентам (экранирования и приведения типов).

Для этого существуют следующие способы:
Для проверки формата строк используют регулярные выражения например, функцию preg_match() в PHP.
Исключение всех тегов или замена спецсимволов на соответствующие HTML-коды для предотвращения выполнения JavaScript на стороне клиента (функции strip_tags() или htmlspecialchars() соответственно.)
Числовые данные перед выводом можно явно привести к числовому типу, например, вызовом функции intval() в PHP.

Слайд 58

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
SQL-INJECTION
Атака заключается в подстановке специальных значений

в параметры, поступающие в SQL-запросы веб-приложения.
Уязвимое к таким атакам приложение не делает должной проверки на формат и экранирования кавычек и спецсимволов в этих данных. В результате такой атаки третья сторона может получить несанкционированный доступ к данным, повредить данные.
Пример. Пусть во время авторизации пользователя на сайте делается такой запрос к базе данных:

/ /Логин и пароль поступают извне и не экранируются. $login = $_POST[’login’]; $password = $_POST[’pass’]; $query = "SELECT * FROM users WHERE login = ’" . $login . "’
AND pass = ’" . $pass . "’"; $result = mysql_query($query);

Слайд 59

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
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’]);

Слайд 60

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
SQL-INJECTION
В данном примере имеется ещё одна

серьезная ошибка – хранение пароля в базе данных открытым текстом. На практике хранят хэши паролей, например с использованием функции md5() в PHP, сами пароли не хранятся нигде, а при необходимости напоминания пароля генерируют новый случайный пароль.

Для предотвращения уязвимостей к SQL-Injection атакам необходимо проверять на соответствие формату и экранировать кавычки и спецсимволы в поступающих от пользователя данных перед использованием их в SQL-запросе, использовать подготовленные запросы (Prepared Statements) при запросах к СУБД, применять библиотеки абстракций, обеспечивающие безопасность при работе с СУБД.

Слайд 61

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
CROSS SITE REQUEST FORGERY
Это атака на

веб-приложение с помощью другого веб-сайта с целью выполнить некоторый запрос к ресурсам в контексте сессии авторизованного пользователя. Для этого авторизованный пользователь должен загрузить уязвимую страницу с формой с сайта третьей стороны или со взломанного сайта и отправить форму методом POST на атакуемый сайт или загрузить ресурс с атакуемого сайта методом GET. Такой запрос, очевидно, будет выполнен в контексте сессии пользователя на атакуемом сайте и может привести к раскрытию данных или потере данных.

Слайд 62

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
CROSS SITE REQUEST FORGERY
Для защиты выполняется

проверка подлинности формы заключается в том, что когда на сервер приходят данные методом POST, веб-приложение проверяет, действительно ли они присланы нашей формой, которую веб-приложение выдало этому пользователю ранее, либо эти данные просто пытаются казаться таковыми.
Для этого в форму добавляется скрытое поле со случайно генерируемой строкой (токеном), который сохраняется на сервере с привязкой к сессии пользователя, данные формы приходят вместе с токеном и перед их принятием проверяется наличие токена в списке выданных ранее.
Токе также может являться хэшем некоторых данных в сессии пользователя и не храниться на сервере явно. Подобный механизм проверки подлинности форм реализован в большинстве развитых фреймворков для создания веб-приложений и систем управления контентом.

Слайд 63

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
UPLOAD-УЯЗВИМОСТИ
В случае когда веб-приложение предоставляет пользователям

возможность загрузить на сервер файл, неправильная обработка загрузки может привести к возможности закачки и исполнения на сервере вредоносного скрипта.
Для исключения Upload-уязвимостей следует проверять расширение загружаемых файлов по белому списку допустимых расширений, помещать загружаемые файлы в каталоги, из которых запрещено выполнение скриптов веб-сервером и следование по символическим ссылкам при поиске файлов и обработчиков веб-запросов.

Слайд 64

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
УТЕЧКА ИНФОРМАЦИИ
В этот пункт попадают

десятки уязвимостей, связанных с раскрытием данных и технических деталей реализации из-за некорректной реализации и настройки веб-приложений. По частоте встречаемости эти уязвимости уступают только уязвимостям к XSS-атакам.
Сообщения об ошибках при обработке некорректных запросов могут приводить к утечке важной информации. После запуска веб-приложения необходимо отключить отображение ошибок и настроить их логирование.

Комментарии в JavaScript и HTML-коде могут привести к раскрытию важных данных. Их следует автоматически удалять из кода перед выдачей клиентам.

Слайд 65

Список использованной литературы
HTTP протокол. http://lectureskpd.readthedocs.io/kpd/3.http.html
Основа www: протокол HTTP. http://www.4stud.info/web-programming/protocol-http.html
Введение в клиент-серверные

технологии Веб. Протокол HTTP. https://www.intuit.ru/studies/courses/485/341/lecture/8182

«WEB-технологии. Протокол HTTP»

Слайд 66

Объект XMLHttpRequest
«WEB-технологии. Протокол HTTP»
Объект XMLHttpRequest в современных браузерах позволяет

после загрузки страницы из JavaScript выполнить HTTP-запрос, получить и обработать ответ без перезагрузки самой страницы.
Запрос можно делать только к ресурсам с именем домена, совпадающим с именем домена, с которого загружена текущая страница. Подобное ограничение называют same-origin policy, и оно применяется во многих веб-технологиях в целях безопасности.
Объект XMLHttpRequest работает в двух режимах: – синхронном, когда в скрипте выполняется вызов метода send() объекта XMLHttpRequest для отправки HTTP-запроса и выполнение скрипта приостанавливается до получения ответа от сервера;
– асинхронном, когда во время и после выполнения запроса работа скрипта продолжается, а при получении ответа вызывается обработчик специального события.

Слайд 67

Объект XMLHttpRequest
«WEB-технологии. Протокол HTTP»
Создание объекта в браузерах: var xmlhttp =

new XMLHttpRequest();
Возможности XMLHttpRequest: – обновление страницы новыми данными без перезагрузки страницы; – запрос и получение данных от сервера после загрузки страницы; – отправка данных на сервер в фоновом режиме.
Методы объекта: abort() – останавливает обработку текущего синхронного запроса; getAllResponseHeaders() – возвращает как строку все заголовки ответа;

Слайд 68

Объект XMLHttpRequest
«WEB-технологии. Протокол HTTP»
Методы объекта (продолжение): getResponseHeader(name) – возвращает значение

заголовка ответа с именем name; open(method, URL, async, login, password) – подготавливает http-запрос указанным методом по указанному адресу: – async – булевский параметр, задает асинхронность запроса; – login, password – логин и пароль для http-авторизации, если на сервере требуется авторизация; - send(content) – отправляет подготовленный ранее запрос, содержимое переменной content передается как сущность запроса;
setRequestHeader(’name’,’value’) – устанавливает значение заголовка запроса с именем name, равным value.

Слайд 69

Объект XMLHttpRequest
«WEB-технологии. Протокол HTTP»
Свойства объекта:
onreadystatechange – событие, вызываемое при

изменении состояния объекта при работе в асинхронном режиме, событию можно назначить свою функцию onreadystatechange = function(event), где readystate – число от 0 до 4, задающее состояние объекта: – 0 – объект не инициализирован; – 1 – идет загрузка; – 2 – загрузка окончена; – 3 – идет обмен с сервером; – 4 – запрос завершен, можно получать результат; responseText – сущность ответа сервера как строка;

responseXML – сущность ответа сервера, разобранная как xmlдокумент; status – HTTP-статус ответа (200, 404 ...); statusText – сообщение статуса (ok, not found ...).

Слайд 70

Объект XMLHttpRequest
«WEB-технологии. Протокол HTTP»
Пример получения фрагмента сервера и вставка

его в текущую страницу без перезагрузки:

Слайд 71

Объект XMLHttpRequest
«WEB-технологии. Протокол HTTP»
Пример отправки данных методом POST:
xmlhttp.open("POST","ajax.php",true); xmlhttp.setRequestHeader("Content-type", "application/x-www-form-urlencoded"); xmlhttp.send("comment=Hello%20World!&name=Anonymous");
Пример обработчика

события onreadystatechange:
xmlhttp.onreadystatechange = function() { if (xmlhttp.readyState == 4 && xmlhttp.status == 200)
{ document.getElementById("myDiv").innerHTML = xmlhttp.responseText; }}

Сессии и Cookie. Безопасность WEB-приложений

Содержание

Лекция 9 Сессии и Cookie Безопасность WEB-приложений Бекэнд - разработка

Вспомним термины «WEB-технологии. Сессии и cookie» Хостинг-провайдер (владелец серверов)обслуживает и предоставляет клиентам

ТерминыХостХост — с точки зрения пользователя как будто то же, что

ТерминыВиртуальный хостЭто хост, не имеющий уникального IP-адреса в Сети, но, тем

ТерминыВиртуальный хостЗамечаниеПонятие "виртуальный хост" не ограничивается только службой Web. Многие другие

ТерминыURL и URIURI (Universal Resource Identifier, универсальный идентификатор ресурса). Очень часто

СессииHTTP веб-сервер не поддерживает постоянного соединения с клиентом, и каждый запрос

СессииЕсли выполнить эти два скрипта, то на первой странице мы увидим

Сессии vs CookieПроцесс выглядел примерно так: пользователь приходит на главную страницу

Такой подход становится очень громоздким и не удобным, как только сайт

При использовании сессий вся информация хранится не на стороне клиента, а

СессииЛюбой скрипт, который будет использовать переменные (данные) из сессий, должен содержать

Сессии// открываем сессиюsession_start();// задаём значение переменной $_SESSION['a'] = "Меня задали на

СессииДругие полезные функции и приемы для работы с сессиями: unset($_SESSION['a']) -

CookieИдентификаторы сессий обычно отправляются браузеру через сессионный cookie и используются для

CookieCookies – расширение протокола HTTP, предназначенное для того, чтобы сохранять на

Cookie (пример)Предположим, нам нужно написать счетчик посещения сайта. Нам нужно знать,

Cookie (пример)Когда пользователь заходит на сайт, нам нужно определить его IP-адрес,

Cookie (пример)Можно использовать второй способ, который намного легче в реализации и

CookieСессия хранится на сервере, Cookie хранятся на клиенте.12345.txt12345.Txtname: Vasyapassvord: *** «WEB-технологии. Сессии

При создании сессии сервер генерирует уникальный идентификатор (идентификатор сессии) и передает

CookieCookies передаются в HTTP открытым текстом в заголовке.Пользователь может задать и

CookieПримеры использования cookies:можно сохранять список товаров в корзине интернет магазина для

CookieФункция для установки cookies в PHP: setcookie ($name, $value, $expire, $path, $domain,

CookieПример функции установки cookies в PHP:if (SetCookie("Test","Value")) echo "Cookie успешно установлен!"; else echo "Cookie установить не удалось!"; ?>Cookies должны устанавливаться до первого

Cookie успешно установлен!

Cookie установить не удалось!

CookieЧтение cookies в PHP:Получить доступ к Cookies и их значениям достаточно

Сессии & cookieПреимущества и недостатки использования сессии по сравнению с cookies:в

Сессии & cookieПреимущества и недостатки использования сессии по сравнению с cookies

Сессии & cookieМетоды идентификации сессии:Идентификатор сессии - это обычная переменная. По

Сессии & cookieМетоды идентификации сессии:Если включена только первая, то при старте

Сессии & cookieМетоды идентификации сессии:По умолчанию в последних версиях PHP включены

Сессии & cookieПример работы с сессией:обновить"; ?> Мы проверяем, есть ли у

Сессии & cookieМетоды защиты сессии: 1) привязка сессии к IP-адресу клиента: после

Сессии & cookieМетоды защиты сессии://стартуем сессию и проверяем авторизацию пользователя session_start();

Авторизация пользователяМеханизм авторизации пользователей в системе с помощью сессий довольно хорош

Авторизация пользователя Вводи пароль

Авторизация пользователяauthorize.phpsession_start(); // данные были отправлены формой? if($_POST['Submit']){ // проверяем данные

Авторизация пользователяauthorize.php Вводи пароль Вы ввели

Авторизация пользователя//открываем сессиюsession_start();echo session_id(); /* просто зайти на эту страницу нельзя...

Авторизация пользователяecho session_id();secretplace.php «WEB-технологии. Сессии и cookie»

Авторизация пользователяecho session_name();secretplace.php «WEB-технологии. Сессии и cookie»

Авторизация пользователя(продолжение) Вводи пароль Привет,

Практическое задание 1Программа авторизации работает не совсем корректно.Найдите ошибку и исправьте

Практическое задание 2Разработать PHP-программу "Тестирование студента на знание языков программирования". Программа

Практическое задание 2Подсказка:Вторая страница теста выглядит примерно так: «WEB-технологии. Сессии и cookie»

Еще о вопросах безопасности WEB-приложений «WEB-технологии. Протокол HTTP» Рассмотрим возможные точки взлома

Еще о вопросах безопасности WEB-приложений «WEB-технологии. Протокол HTTP» Как "залатать" дыру номер

Еще о вопросах безопасности WEB-приложений «WEB-технологии. Протокол HTTP» if(preg_match("/^$SERVER_ROOT/",$_SERVER['HTTP_REFERER'])){ // данные были

Еще о вопросах безопасности WEB-приложений «WEB-технологии. Протокол HTTP» Как избавиться от "дыры"

Еще о вопросах безопасности WEB-приложений «WEB-технологии. Протокол HTTP» В принципе, любую переменную

Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» Уязвимости приложений могут быть использованы злоумышленниками

Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» CROSS SITE SCRIPTINGАтака Cross Site Scripting

Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» CROSS SITE SCRIPTINGРассмотрим пример. Предположим, на

Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» CROSS SITE SCRIPTINGПосле перехода по ней

Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» CROSS SITE SCRIPTINGВ данном примере содержится

Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» CROSS SITE SCRIPTINGДля предотвращения уязвимостей к

Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» SQL-INJECTIONАтака заключается в подстановке специальных значений

Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» SQL-INJECTION/ /Логин и пароль поступают извне

Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» SQL-INJECTIONВ данном примере имеется ещё одна

Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» CROSS SITE REQUEST FORGERYЭто атака на

Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» CROSS SITE REQUEST FORGERYДля защиты выполняется

Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» UPLOAD-УЯЗВИМОСТИВ случае когда веб-приложение предоставляет пользователям

Вопросы безопасности WEB-приложений «WEB-технологии. Протокол HTTP» УТЕЧКА ИНФОРМАЦИИ В этот пункт попадают

Список использованной литературыHTTP протокол. http://lectureskpd.readthedocs.io/kpd/3.http.htmlОснова www: протокол HTTP. http://www.4stud.info/web-programming/protocol-http.htmlВведение в клиент-серверные

Объект XMLHttpRequest «WEB-технологии. Протокол HTTP» Объект XMLHttpRequest в современных браузерах позволяет

Объект XMLHttpRequest «WEB-технологии. Протокол HTTP» Создание объекта в браузерах: var xmlhttp =

Объект XMLHttpRequest «WEB-технологии. Протокол HTTP» Методы объекта (продолжение): getResponseHeader(name) – возвращает значение

Объект XMLHttpRequest «WEB-технологии. Протокол HTTP» Свойства объекта: onreadystatechange – событие, вызываемое при

Объект XMLHttpRequest «WEB-технологии. Протокол HTTP» Пример получения фрагмента сервера и вставка

Похожие презентации

Лекция 9 Сессии и Cookie Безопасность WEB-приложений
Бекэнд - разработка

Вспомним термины
«WEB-технологии. Сессии и cookie»
Хостинг-провайдер (владелец серверов)
обслуживает и предоставляет клиентам

Термины
Хост
Хост — с точки зрения пользователя как будто то же, что

Термины
Виртуальный хост
Это хост, не имеющий уникального IP-адреса в Сети, но, тем

Термины
Виртуальный хост
Замечание
Понятие "виртуальный хост" не ограничивается только службой Web.
Многие другие

Термины
URL и URI
URI (Universal Resource Identifier, универсальный идентификатор ресурса). Очень часто

Сессии
HTTP веб-сервер не поддерживает постоянного соединения с клиентом, и каждый запрос

Сессии
Если выполнить эти два скрипта, то на первой странице мы увидим

Сессии vs Cookie
Процесс выглядел примерно так: пользователь приходит на главную страницу

Сессии
Любой скрипт, который будет использовать переменные (данные) из сессий, должен содержать

Сессии
// открываем сессию
session_start();
// задаём значение переменной
$_SESSION['a'] = "Меня задали на

Сессии
Другие полезные функции и приемы для работы с сессиями:
unset($_SESSION['a']) -

Cookie
Идентификаторы сессий обычно отправляются браузеру через сессионный cookie и используются для

Cookie
Cookies – расширение протокола HTTP, предназначенное для того, чтобы сохранять на

Cookie (пример)
Предположим, нам нужно написать счетчик посещения сайта. Нам нужно знать,

Cookie (пример)
Когда пользователь заходит на сайт, нам нужно определить его IP-адрес,

Cookie (пример)
Можно использовать второй способ, который намного легче в реализации и

Cookie
Сессия хранится на сервере, Cookie хранятся на клиенте.
12345.txt
12345.Txt
name: Vasya
passvord: ***
«WEB-технологии. Сессии

Cookie
Cookies передаются в HTTP открытым текстом в заголовке.
Пользователь может задать и

Cookie
Примеры использования cookies:
можно сохранять список товаров в корзине интернет магазина для

Cookie
Функция для установки cookies в PHP:
setcookie ($name, $value, $expire, $path, $domain,

Cookie
Пример функции установки cookies в PHP:
if (SetCookie("Test","Value")) echo "
Cookie успешно установлен!
"; else echo "
Cookie установить не удалось!
";
?>
Cookies должны устанавливаться до первого

Cookie
Чтение cookies в PHP:
Получить доступ к Cookies и их значениям достаточно

Сессии & cookie
Преимущества и недостатки использования
сессии по сравнению с cookies:
в

Сессии & cookie
Преимущества и недостатки использования сессии по сравнению с cookies

Сессии & cookie
Методы идентификации сессии:
Идентификатор сессии - это обычная переменная. По

Сессии & cookie
Методы идентификации сессии:
Если включена только первая, то при старте

Сессии & cookie
Методы идентификации сессии:
По умолчанию в последних версиях PHP включены

Сессии & cookie
Пример работы с сессией:
обновить"; ?>
Мы проверяем, есть ли у

Сессии & cookie
Методы защиты сессии:
1) привязка сессии к IP-адресу клиента: после

Сессии & cookie
Методы защиты сессии:
//стартуем сессию и проверяем авторизацию пользователя session_start();

Авторизация пользователя
Механизм авторизации пользователей в системе с помощью сессий довольно хорош

Авторизация пользователя

Вводи пароль

Авторизация пользователя
authorize.php
session_start();
// данные были отправлены формой?
if($_POST['Submit']){
// проверяем данные

Авторизация пользователя
authorize.php

Вводи пароль

Вы ввели

Авторизация пользователя
//открываем сессию
session_start();
echo session_id();
/*
просто зайти на эту страницу нельзя...

Авторизация пользователя
echo session_id();
secretplace.php
«WEB-технологии. Сессии и cookie»

Авторизация пользователя
echo session_name();
secretplace.php
«WEB-технологии. Сессии и cookie»

Авторизация пользователя
(продолжение)

Вводи пароль

Привет,

Практическое задание 1
Программа авторизации работает не совсем корректно.
Найдите ошибку и исправьте

Практическое задание 2
Разработать PHP-программу "Тестирование студента на знание языков программирования". Программа

Практическое задание 2
Подсказка:
Вторая страница теста выглядит примерно так:
«WEB-технологии. Сессии и cookie»

Еще о вопросах безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
Рассмотрим возможные точки взлома

Еще о вопросах безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
Как "залатать" дыру номер

Еще о вопросах безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
if(preg_match("/^$SERVER_ROOT/",$_SERVER['HTTP_REFERER'])){
// данные были

Еще о вопросах безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
Как избавиться от "дыры"

Еще о вопросах безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
В принципе, любую переменную

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
Уязвимости приложений могут быть использованы злоумышленниками

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
CROSS SITE SCRIPTING
Атака Cross Site Scripting

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
CROSS SITE SCRIPTING
Рассмотрим пример. Предположим, на

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
CROSS SITE SCRIPTING
После перехода по ней

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
CROSS SITE SCRIPTING
В данном примере содержится

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
CROSS SITE SCRIPTING
Для предотвращения уязвимостей к

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
SQL-INJECTION
Атака заключается в подстановке специальных значений

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
SQL-INJECTION
/ /Логин и пароль поступают извне

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
SQL-INJECTION
В данном примере имеется ещё одна

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
CROSS SITE REQUEST FORGERY
Это атака на

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
CROSS SITE REQUEST FORGERY
Для защиты выполняется

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
UPLOAD-УЯЗВИМОСТИ
В случае когда веб-приложение предоставляет пользователям

Вопросы безопасности WEB-приложений
«WEB-технологии. Протокол HTTP»
УТЕЧКА ИНФОРМАЦИИ
В этот пункт попадают

Список использованной литературы
HTTP протокол. http://lectureskpd.readthedocs.io/kpd/3.http.html
Основа www: протокол HTTP. http://www.4stud.info/web-programming/protocol-http.html
Введение в клиент-серверные

Объект XMLHttpRequest
«WEB-технологии. Протокол HTTP»
Объект XMLHttpRequest в современных браузерах позволяет

Объект XMLHttpRequest
«WEB-технологии. Протокол HTTP»
Создание объекта в браузерах: var xmlhttp =

Объект XMLHttpRequest
«WEB-технологии. Протокол HTTP»
Методы объекта (продолжение): getResponseHeader(name) – возвращает значение

Объект XMLHttpRequest
«WEB-технологии. Протокол HTTP»
Свойства объекта:
onreadystatechange – событие, вызываемое при

Объект XMLHttpRequest
«WEB-технологии. Протокол HTTP»
Пример получения фрагмента сервера и вставка