forked from vlsergey/infosec
-
Notifications
You must be signed in to change notification settings - Fork 0
/
cookies_auth.tex
59 lines (45 loc) · 10.6 KB
/
cookies_auth.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
\subsection{Вторичная аутентификация по cookie}
\selectlanguage{russian}
Если сервер использует первичную аутентификацию по паролю, который передаётся в виде данных POST-запроса, то осуществлять подобную передачу данных при каждом обращении неудобно. Клиент должен иметь возможность доказать серверу, что он уже прошёл первичную аутентификацию. Должен быть предусмотрен механизм вторичной аутентификации. Для этого используется случайный токен, который уникален для каждого пользователя (обычно -- для каждого сеанса работы пользователя), который сервер передаёт пользователю после первичной аутентификации. Данный токен должен передаваться клиентом на сервис при каждом обращении к страницам, которые относятся к защищённой области сервиса. На практике применяются следующие механизмы для передачи данного токена при каждом запросе.
\begin{itemize}
\item Первым способом является модификация вывода страницы клиенту, которая добавляет ко всем URL в HTML-коде страницы этот токен. В результате, переходя по ссылкам на HTML-странице (а также заполняя формы и отправляя их на сервер), клиент будет автоматически отправлять токен как часть запроса в URL-адресе страницы:
\texttt{http://tempuri.org/page.html?token=12345.}
\item Вторым способом является использование механизма cookie (<<куки>>, <<кукиз>>, на русский обычно не переводится, подробнее см.~\cite[Client Identification and Cookies]{Totty:2002}). Данный механизм позволяет серверу передать пользователю некоторую строку, которая будет отправляться на сервер при каждом последующем запросе.
\end{itemize}
Основным механизмом для вторичной аутентификации пользователей в веб-сервисах является механизм cookie, а токены, как часть URL, используются в распределённых системах, вроде уже рассмотренной OpenID, так как сервисы, находящиеся в разных доменах, не имеют доступа к общим cookie. Далее рассмотрим подробнее механизм использования cookie.
Когда браузер в первый раз делает HTTP-запрос:
\begin{center} \begin{verbatim}
GET /index.html HTTP/1.1
Host: www.wikipedia.org
Accept: */*
\end{verbatim} \end{center}
В заголовок ответа сервера веб-приложение может добавить заголовок \texttt{Set-Cookie}, который содержит новые значения cookie:
\begin{center} \begin{verbatim}
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name1=value1; name2=value2; ...
...далее HTML-страница...
\end{verbatim} \end{center}
Браузер, если это разрешено настройками, при последующих запросах к веб-серверу автоматически будет отсылать cookie назад веб-приложению:
\begin{center} \begin{verbatim}
GET /wiki/HTTP_cookie HTTP/1.1
Host: www.wikipedia.org
Cookie: name1=value1; name2=value2; ...
Accept: */*
\end{verbatim} \end{center}
Далее веб-приложение может создать новый cookie, изменить значение старого и~т.\,д. Браузер хранит cookie на устройстве клиента. То есть cookie позволяет хранить переменные на устройстве клиента, отсылать сохранённые значения, получать новые переменные. В результате создаётся передача состояний, что даёт возможность не вводить логин и пароль каждый раз при входе в интернет-сервис, использовать несколько окон для одного сеанса работы в интернет-магазине и~т.\,д. При создании cookie может указываться его конечное время действия, после которого браузер удалит устаревший cookie.
Для вторичной аутентификации в cookie веб-приложение записывает токен в виде текстовой строки. В качестве токена можно использовать \emph{псевдослучайную} текстовую строку достаточной длины, созданную веб-приложением. Например:
\begin{center} \begin{verbatim}
Cookie: auth=B35NMVNASUY26MMWNVZ87.
\end{verbatim} \end{center}
В этом случае веб-сервис должен вести журнал выданных токенов пользователям и их сроков действия. Если информационная система небольшого размера (один или десятки серверов), то вместо журнала может использоваться механизм session storage.
\begin{itemize}
\item При первом заходе на сайт сервер приложений (платформа исполнения веб-приложения) <<назначает>> клиенту сессию, отправляя ему через механизм cookie новый (псевдо)случайный токен сессии, а в памяти сервера выделяя структуру, которая недоступна самому клиенту, но которая соответствует данной конкретной сессии.
\item При каждом последующем обращении клиент передаёт токен (идентификатор) сессии с помощью механизма cookie. Сервер приложений берёт из памяти соответствующую структуру сессии и передаёт её приложению вместе с параметрами запроса.
\item В момент прохождения первичной аутентификации приложение добавляет в указанную область памяти ссылку на информацию о пользователе.
\item При последующих обращениях приложение использует информацию о пользователе, записанную в области памяти сессии клиента.
\item Сессия автоматически стирается из памяти после прохождения некоторого времени неактивности клиента (что контролируется настройками сервера) либо если приложение явно вызвало функцию инвалидации сессии (\langen{invalidate}).
\end{itemize}
Плюсом использования session storage является то, что этот механизм уже реализован в большинстве платформ для построения веб-приложений (см., например, \cite[Controlling sessions]{Brittain:Darwin:2007}). Его минусом является сложность синхронизации структур сессий в памяти серверов для распределённых информационных систем большого размера.
Вторым способом вторичной аутентификации с использованием cookie является непосредственное включение аутентификационных данных (идентификатор пользователя, срок действия) в cookie вместо случайного токена. К данным в обязательном порядке добавляется имитовставка\index{имитовставка} по ключу, который известен только сервису. С одной стороны, данный подход может значительно увеличить размер передаваемых cookie. С другой -- он облегчает вторичную аутентификацию в распределённых системах, так как промежуточным сервисом, хранящим информацию о произошедшей аутентификации, является только клиент, а не сервер.
Конечно, беспокоиться об аутентификации в веб-сервисах при использовании обычного HTTP-протокола\index{протокол!HTTP} без зашифрованного SSL-соединения\index{протокол!SSL/TLS} имеет смысл только по отношению к угадыванию токенов аутентификации другими пользователями, которые не имеют доступа к маршрутизаторам и сети, через которые клиент общается с сервисом. Кража компьютера или одного cookie-файла и перехват незащищённого трафика протокола HTTP\index{протокол!HTTP} приводят к доступу в систему под именем взломанного пользователя.