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

Содержание

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

Слайд 1Курс
«Программирование в компьютерных сетях»

Лекция 9

Приходько Татьяна Александровна
доцент кафедры
Вычислительных технологий

КубГУ

Слайд 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Сессии

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»

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

и cookie»

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

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

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

Сессии & cookie

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

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

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

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

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

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

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

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

Слайд 25Cookie
Функция для установки 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»

Слайд 26Cookie
Пример функции установки cookies в PHP:

Cookies должны устанавливаться до первого

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

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

Слайд 27Cookie
Чтение 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Авторизация пользователя


Вводи пароль




Логин:

Пароль:





index.php

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

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

проверяем данные на правильность... в данном случае
// имя пользователя и пароль вписан прямо в код,
// целесообразней было бы проверить логин/пароль в базе
// данных и при совпадении дать доступ пользователю...
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Авторизация пользователя

нельзя... Если
имя пользователя не зарегистрировано, то
перенаправляем его на страницу 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Авторизация пользователя
(продолжение)


Вводи пароль

charset="utf-8"/>


Привет, , ты на секретной странице!!! :)




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'])){
// данные были

отправлены формой?
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

Привет, , ты на секретной странице! 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; }}

Слайд 72Объект XMLHttpRequest
«WEB-технологии. Протокол HTTP»
В данном примере создается анонимная функция

без параметров и присваивается в качестве обработчика события onreadystatechange.
Пример c использованием библиотеки jQuery: // Загрузка содержимого элемента #myDiv // с сервера методом GET. $(’#myDiv’).load(’/ajax.php’); // Асинхронный POST-запрос. $.ajax({ type: "POST", url: "/ajax.php", data: "key1=value1&key2=value2", beforeSend: function(XHR) { // Задаем заголовки запроса.
}, success: function(){ // Обрабатываем ответ. } });

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

Графический редактор Adobe Photoshop. История создания 358
Структуры данных. Диаграмма потоков данных 271
Разработка проекта комплексной системы программно-аппаратной защиты информации предприятия 342
Лекция 2. Государственная СЗИ 348
Шифр және шифрлау 776
The process model 288

Обратная связь

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

Email: Нажмите что бы посмотреть 

Что такое ThePresentation.ru?

Это сайт презентаций, докладов, проектов, шаблонов в формате PowerPoint. Мы помогаем школьникам, студентам, учителям, преподавателям хранить и обмениваться учебными материалами с другими пользователями.

Для правообладателей

Яндекс.Метрика