forked from vlsergey/infosec
-
Notifications
You must be signed in to change notification settings - Fork 0
/
cookies_auth.tex
66 lines (53 loc) · 7.51 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
60
61
62
63
64
65
66
\subsection{Вторичная аутентификация по cookie}
\selectlanguage{russian}
Протокол HTTP\index{протокол!HTTP} не поддерживает запоминание состояния соединения. Все запросы браузера интернет-сервису неотличимы от того, происходят они в первый раз или последующие. Поэтому для образования связности взаимодействия браузера и интернет-сервиса вводят искусственно <<состояние>> либо с помощью cookie, либо внедряют как часть URL, либо применяя скрытые элементы в формах.
Пример передачи переменных через URL: \\
\texttt{http://en.wikipedia.org/w/index.php? \\
\hspace*{1 cm} title=Hypertext\_Transfer\_Protocol\& \\
\hspace*{1 cm} action=historysubmit\&diff=330577492\&oldid=330543455}, \\
где браузер при запросе к веб-сервису указывает значения переменных: \texttt{ \\
\hspace*{1 cm} title = Hypertext\_Transfer\_Protocol, \\
\hspace*{1 cm} action = historysubmit, \\
\hspace*{1 cm} diff = 330577492, \\
\hspace*{1 cm} oldid = 330543455.
}
В скрытых элементах форм языка разметки HTML, которые не показываются браузером на веб-странице, веб-сервер передает установленные значения переменных, которые браузер отправит назад сервису вместе с отправкой других видимых полей формы: \texttt{ \\
\hspace*{1 cm} <input type="hidden"\ name="user"\ value="john"/> \\
\hspace*{1 cm} <input type="hidden"\ name="birthdate" \\
\hspace*{2 cm} value="29.02.1986"/> \\
\hspace*{1 cm} <input type="hidden"\ name="age"\ value="3"/>
}
Вторичная аутентификация при каждом HTTP-запросе, как правило, реализуется через cookie, которые браузер сохраняет в своем кэше посещенных страниц. Первоначально cookie были разработаны для возможности создания интернет-магазина.
Когда браузер в первый раз делает HTTP-запрос
\begin{center} \begin{verbatim}
GET /index.html HTTP/1.1
Host: www.wikipedia.org
\end{verbatim} \end{center}
к веб-серверу, веб-приложение сервера может отправить HTTP-пакет, содержащий параметр, строку текста, 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.
Для вторичной аутентификации в cookie веб-приложение записывает аутентификатор в виде текстовой строки.
В качестве аутентификатора можно использовать \emph{псевдослучайную} текстовую строку достаточной длины, сгенерированную веб-приложением. Веб-приложение должно вести журнал выданных аутентификаторов пользователям и их сроков действия. Например,
\begin{center} \begin{verbatim}
Cookie: auth=B35NMVNASUY26MMWNVZ87
\end{verbatim} \end{center}
Вторым способом аутентификации является применение кода аутентификации сообщений ко всем данным, записанным в cookie. Код аутентификации сообщений $\MAC_K$ на секретном ключе $K = h(m \| s)$, который является хэшем от пароля $m$ и соли $s$, вычисляется от псевдослучайной одноразовой метки $\textrm{nonce}$, имени пользователя $user$ и других данных $data$, сохраняемых в cookie:
\begin{center} \begin{verbatim}
Cookie: User=user; Nonce=nonce; Data=data; MAC=auth;
\end{verbatim} \end{center}
\[ auth = \HMAC_K(user \| \textrm{nonce} \| data). \]
Псевдослучайный аутентификатор предпочтительнее, так как позволяет гарантировать, что аутентификатор был создан веб-приложением, и не раскрывает имени пользователя. Использование кода аутентификации сообщения является дополнительной мерой того, что данные, сохраняемые в cookie, не были подделаны.
Конечно, беспокоиться об аутентификации в интернет-сервисах при использовании обычного HTTP-протокола\index{протокол!HTTP} без зашифрованного SSL-соединения\index{протокол!SSL/TLS} имеет смысл только по отношению к угадыванию токенов аутентификации другими пользователями, которые не имеют доступа к маршрутизаторам и сети, через которые общается пользователь. Кража компьютера или одного cookie-файла, перехват незащищенного трафика протокола HTTP\index{протокол!HTTP} приводят к доступу в систему под именем взломанного пользователя.