close

Вход

Забыли?

вход по аккаунту

Иванов Алексей Юрьевич. Анализ безопасности открытого протокола OAuth в среде ProVerif

код для вставки
"o],Ivoa.H.s
8
l0a
u$o
2a-t/
,,{rr.sr xEssoldDndooHH
{[email protected]'@€
sos?sl4 o{ Y
(gtro^o.td
e!.dr s WnyO ?rororod! ororrqdxrc rmos.eroc.g rrr€Hv>
Icrcgsd [email protected], loBr{urqs RnJr
4rroroHxe!ressorftndoos!rrrrDererors,ns.odrodogld! J"(x{I.slI
9flS91 do"f,
rhlj3.qdo{ 3.rr!!r'' ffosesu eurv{trJ
Fnsrctt 0lqHHorrE^[email protected]{E"dordo) (srroodr) [email protected]!€lt
r€ftRl.)lrd[ t0.n0.60
"rne^doocr
msdornon qrs.medrec ou
vJosIYd
r\/HHolIIft )uoulf Y€DiI r\/[DIc,{JIIqg
<.vqs{gJd
J
c I4I4H!tr^U]
.lalIIJdAgttIA IjIqHHA€IIC{VI,{ JOl FDICSOIIdO)
rIllHY€IO€VdSO
OJgmCIqe !trXfi Ifxtritrtl
Jol aoHsl.yddao
qoH{rg.IY€IoEvdgo aoHllD(trols qoHIfl slcdvl,{
ZLf MtrAO 4O)IJ&[,I)JOd I/DI^ YH I{ KITHVSO€YdSO OtI.lCdgICl{IlI4^I
dta bmredollss nr"rerIE.d t E
{osoryecx6^ ro lt.uuo3 cllu.do
t
sJ,€
otsH{o!.o rBlnoiex?dgoro 'llln?rrotedtl
entdel?,'{ orocsolr€drrconetr qse6od.[
S
€lemr6 r solodrED nuoffou
qmvo sorcrorod! xIsrEdM Isl,llfirt I{doD
lceuuoc cpedo t qnYo sorolorods xsmdM .tH?soE6rtcl4
mlIE [email protected] t nnrrexr+eH.rft Mdorodu oleusdro .rsHHo^'dsoC
(sooduos s'IoqedPd sltrRv.rdou cH.sidsur /rJrusr IoHs5ruHJsou MHryd)voJ
t
ur.ergo locDHv.du
o
MlEndoosn :retdd€,{ wncthnedo.I
do9€d x eEEq8n .nBYoxcI4
E
'{toz [email protected] <!zt r{ogBd uoHHoLEotot ,'norH.Yftc !h?vr xodc z
tlo€-z dN rr l0z rdg3Do (I P m ,&.Iu.d.sts,{ ou ,{oEetud! "s.Iddedr
qua^ord 3Eadc s $nYo erdolod! d'Nd o tbos.ero..g turesY> dxg RntI I
€n}lsasdo{ rocto!'Ic {oE3I4 e {.E{l
9r199r d{rtrr
tshged 4oHHo'rHEouns' 4oHtcrrnd.'s.sro,rFs ec
lMI{VtrV€
'
'rat
OZ
NNosHEt/=/.
todr.oa's?€
:orvfixdasl
s'{oluc eEBHo'rne^dooHu.Ess!'&doudo) (snoodu) qr.ossers?dtrEli
ffifielltsdu €0 t0 60 [email protected]
"xj.!sr{do0st t{.$n. KqnHouft ndoos' !dveo,}
|'roro*sxlcccotiPv{doos!tttneetr"noss'Btq.odrsodogtrdn rDsH
<Yqfl{glil
|J
I4
I4H![^&r
Jqurcdasrxi/! ltl1trfi qalcdqtr^coJ LMxJsolrdot
rI4rMO€YdgOOJflnCIqS {tdxadrtt
qoHltrJSrYgOwdgO IIOHIOIdOIS AOIIIfi SICi|CV^JOI AoHitrrvddao
!tr-dwddsq ltoxqMJcod I,uIvH
rr
trlHvgo€vd:Io
ogrcd![culff {
"15, mperr 2018..
Qrrrl
3a,aaHre npxHrn k
trcnoiHeHro
KANEHNA"HbIII IINAH
ttulMenoBasre srdoB paoord
AHU!3 co8peMemn orKpurffi
nloroKoroB atreErH+rmqry !
t6 04 20t3 -.25.04.2013
sroPrcaqM
lccneAoBdre orKplrHx
nporoKnoB OAuth
r OpenID
26 0.4.20t3
Pa3pa6oBa MeroroB 3autard
ntoro&onoB OAuth
OpenID Comeci m MexcaiiroBot
no.q.qenM 3anpocoB r ourrHra
wlHrn
oQopuenae norcamairo;
3anrcK, BKP ! rpa+rsec(oro
MareDr{arra
t
-
10.05..:018
11.05.2018 I0.06,2018
r
r.06 2018- 25.06.2013
АННОТАЦИЯ
ВКР 114 с., 31 рис., 3 табл., 25 источников.
АНАЛИЗ,
ИССЛЕДОВАНИЕ,
ОТКРЫТЫЙ
ПРОТОКОЛ,
OAUTH,
OPENID CONNECT, PROVERIF, ФИШИНГ, МЕЖСАЙТОВАЯ ПОДДЕЛКА
ЗАПРОСА.
Выпускная квалификационная работа посвящена анализу безопасности
открытого протокола OAuth в среде ProVerif.
Выпускная квалификационная работа состоит из введения, трех глав,
заключения, списка литературы и приложения А.
В первой главе обосновывается актуальность данной работы, описываются
современные открытые протоколы аутентификации и авторизации, варианты
использования и виды открытых протоколов.
Во второй главе исследуются отрытые протоколы OAuth и OpenID Connect,
выбирается инструментальное средство для анализа открытых протоколов и
предлагаются методы для улучшения этих протоколов.
В третьей главе рассматриваются основные виды межсайтовых подделок
запросов, разрабатываются методы защиты открытых протоколов OAuth и OpenID
Connect от межсайтовой подделки запросов и фишинга.
В заключении сделаны основные выводы по выпускной квалификационной
работе.
4
СОДЕРЖАНИЕ
СПИСОК ИСПОЛЬЗУЕМЫХ ОПРЕДЕЛЕНИЙ
6
ВВЕДЕНИЕ
10
1 СОВРЕМЕННЫЕ ОТКРЫТЫЕ ПРОТОКОЛЫ АУТЕНТИФИКАЦИИ
И АВТОРИЗАЦИИ
12
1.1 Задачи аутентификации и авторизации
12
1.2 Описание открытого протокола OAuth
13
1.2.1 Последовательность шагов веб приложения, работающего на
стороне сервера
20
1.2.2 Последовательность шагов веб приложения, работающего на
стороне клиента
26
1.2.3 Последовательность шагов веб приложения, основанного на
учетных данных владельца ресурса
28
1.2.4 Последовательность шагов веб приложения, основанного на
учетных данных клиента
31
1.3 Описание открытого протокола OpenID Connect
33
2 ИССЛЕДОВАНИЕ ОТКРЫТЫХ ПРОТОКОЛОВ OAUTH И OPENID
CONNECT
39
2.1 Анализ и выбор инструментального средства для анализа открытых
протоколов OAuth и OpenID Connect
39
2.2 Анализ открытого протокола OAuth
64
2.3 Анализ открытого протокола OpenID Connect
74
2.3.1 Формализация протокола OpenID Connect с использованием
прикладного Пи-исчисления
2.3.2
Автоматическая
проверка
78
безопасности
и
аутентификации
открытого протокола OpenID Connect с помощью инструмента ProVerif
3 МЕТОДЫ ЗАЩИТЫ ОТКРЫТЫХ ПРОТОКОЛОВ OAUTH И OPENID
CONNECT
ОТ
МЕЖСАЙТОВОЙ
ПОДДЕЛКИ
ЗАПРОСОВ
И
84
5
ФИШИНГА
88
3.1 Межсайтовая подделка запроса в открытых протоколах OAuth и
OpenID Connect
88
3.1.1 Описание и виды межсайтовой подделки запроса
89
3.1.2 Защита метода «код авторизации» от межсайтовой подделки
запроса
93
3.1.3 Защита «неявного» метода от межсайтовой подделки запроса
95
3.2 Защита OAuth от фишинга
97
3.2.1 Описание и архитектура модифицированной версии OAuth
97
3.2.2 Оценка эффективности модифицированной версии OAuth
101
ЗАКЛЮЧЕНИЕ
105
СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ
106
ПРИЛОЖЕНИЕ А
109
УДОСТОВЕРЯЮЩИЙ ЛИСТ
112
ИНФОРМАЦИОННО-ПОИСКОВАЯ ХАРАКТЕРИСТИКА
ДОКУМЕНТА НА ЭЛЕКТРОННОМ НОСИТЕЛЕ
113
6
СПИСОК ИСПОЛЬЗУЕМЫХ ОПРЕДЕЛЕНИЙ
Аутентификация – это процесс, в котором предоставленные учетные данные
пользователя сравниваются с данными базы авторизированных пользователей в
локальной операционной системе или на сервере аутентификации. Если учетные
данные совпадают, процесс завершается, и пользователю предоставляется
разрешение на доступ. Если данные не совпадают, система предупреждает, что
данные являются ошибочными и разрешение на доступ не предоставляется.
Авторизация – это процесс проверки того, что пользователь имеет право
выполнять некоторые действия, такие как чтение документа или доступ к учетной
записи электронной почты. Обычно для этого требуется действительная
идентификация пользователя (аутентификация), чтобы проверить, разрешено ли
данному пользователю это действие. Веб приложение сначала проверяет вашу
личность, регистрируя вас, а затем обеспечивает доступ только к тем данным и
службам, доступ к которым вам разрешен, как правило, путем проверки списка
управления доступом для каждой операции.
Протокол – общий набор правил и инструкций, с помощью которых
компьютеры осуществляют коммуникацию друг с другом. В следствии того, что
компьютеры могут обмениваться информацией друг с другом, существует много
разных протоколов – слишком много для обычного человека. Некоторые примеры
этих протоколов PPP, TCP/IP, SLIP, HTTP и FTP.
Сессия (сеанс) – ограниченный период времени между двумя системами.
Некоторые сессии включают в себя клиента и сервер, а в других сессиях
задействованы два персональных компьютера. Стандартный тип сессии – сессия
Web или HTTP. HTTP сессия инициируется веб-браузером при каждом посещении
веб-сайта. Каждый визит на страницу представляет собой отдельную сессию, этот
термин часто используется для описания всего времени, проведенного на вебсайте.
7
Сервер ресурсов – сервер, на котором размещаются ресурсы пользователя.
Обычно это поставщик API, который хранит и защищает данные, такие как
фотографии, видео, календари или контакты.
Владелец ресурса – пользователь, который авторизует приложение для
доступа к своему аккаунту. Доступ приложения к пользовательскому аккаунту
ограничен областью видимости.
Клиент – приложение, которое хочет осуществить доступ к аккаунту
пользователя для выполнения действий над защищенными ресурсами от имени
владельца ресурса и с его авторизацией.
Сервер авторизации – сервер, который получает согласие от владельца
ресурса и выдает токены доступа клиентам для доступа к защищенным ресурсам,
размещенным на сервере ресурсов. Поставщики API, не такие как, например,
гиганты Google или Yandex, могут использовать одно и то же приложение и
пространство URL как для сервера авторизации, так и для сервера ресурсов.
Криптография
преобразовываются
–
в
это
наука
безопасный
о
защите
формат.
информации,
Этот
где
процесс,
данные
называемый
шифрованием, использовался на протяжении веков, чтобы предотвратить чтение
рукописных
сообщений
непреднамеренными
получателями.
Сегодня
криптография используется для защиты цифровых данных.
Шифрование – обратимое преобразование информации в целях сокрытия от
неавторизованных лиц, с предоставлением, в это же время, авторизованным
пользователям доступа к ней.
Дешифрование – получение открытых данных по зашифрованным в
условиях, когда алгоритм расшифрованния его секретные параметры не являются
полностью известными и расшифрованные не может быть выполнено обычным
путем.
Проверочный шлюз – это достоверный секретный ключ сервера, который
используется для отправки проверочной информации и получения ответной
информации. Он играет важную роль во всей системе, поскольку проверяет
идентификацию пользователей через методы связи (такие как СМС или Email) и
8
может предостеречь клиента OAuth от фишинг атаки.
Сервер генерирует
случайную и уникальную проверочную информацию на основе авторизационных
данных пользователя и отправляет её пользователю, у которого имеется мобильное
устройство или адрес электронной почты, таким образом избегая фишинговых
страниц, которые могут украсть пользовательский логин и пароль.
Информационный шлюз – это сервер, откуда отправляется проверочная
информация, и где будет получена ответная информация. Предполагается, что
информационный шлюз является контролируемым, безопасным и надежным.
Пользователь ссылается либо на мобильное приложение, либо на браузер. В
условиях OAuth вместо пользователя используется владелец ресурса.
Проверочный клиент фактически относится к мобильному устройству
пользователя или электронной почте, которое может получать информацию от
проверочного шлюза и отправлять.
OAuth клиент – это стороннее приложение, которое уполномочено получать
данные пользователей через API OAuth.
У сервера авторизации имеется централизованная аутентификация и
унифицированная функция авторизации. Сервер авторизации проверяет запросы
пользователей или клиентов и контролирует, когда пользователь проходит
авторизацию и когда клиент получает проверочную информацию от проверочного
шлюза.
Сервер ресурсов предоставляет местоположение, где хранятся личные и
общедоступные данные пользователей. Клиент может выполнять безопасные
операции с данными пользователей, только когда он прошел проверку авторизации
на сервере авторизации. В оригинальном протоколе OAuth это относится к
ресурсной части поставщика услуг.
Токен – уникальный идентификатор, выданный сервером. С помощью
токена доступа, клиент может получить доступ к защищенным ресурсам на сервере
ресурсов.
9
Зашифрованные данные – это пара случайных кодов, скомбинированные
уникальным цифровым идентификатором и совпадающие с общим секретным
ключом.
Пользовательские данные – это набор данных, используемый сервером для
уникальной идентификации пользователя и проверки подлинности пользователя.
Они генерируются на основе информации пользователя (имени пользователя или
клиентского приложение) и проверочной информации, с помощью алгоритмов
безопасности.
Клиентские данные – это набор данных, состоящих из идентификатора
клиента и пароля клиента.
Временные данные – это данные, состоящие из кода авторизации.
Данные токена – это данные, состоящие из токена доступа.
10
ВВЕДЕНИЕ
Информация является важной составляющей для организаций и частных
лиц. Раскрытие, ненадлежащее изменение или недоступность информации могут
повлечь за собой расходы или упущенные выгоды. Поэтому большинство в
определенной степени защищают информацию.
Информационная безопасность должна учитывать три основных правила:
защита конфиденциальности, целостности и доступности информации. Концепция
построения безопасности информационных систем различает множество подходов.
На уровне идентификации, аутентификации, авторизации пользователей и прав
пользователей было разработано множество протоколов и приложений, которые
повышают уровень безопасности систем. Криптография и кодирование являются
основными способами защиты данных. Кроме того, используются несколько
методов и протоколов обмена ключами, которые играют решающую роль в
шифровании
и
аутентификации
пользователей.
Определение
политик
безопасности и проектирование элементов безопасности приводят к созданию
безопасной и защищенной среды.
С развитием Интернета и других открытых сетей было разработано и
развернуто большое количество протоколов для обеспечения безопасной связи.
Анализ таких протоколов безопасности оказался чрезвычайно трудным, и во
многих протоколах были найдены серьезные уязвимости. К сожалению, пока нет
эффективных подходов к построению правильных и эффективных протоколов, и
работа над формальной логикой, которая может позволить легко доказать, что
протокол безопасен в формальной модели, все еще продолжается. Самым
эффективным подходом на сегодняшний день является автоматизированные
инструментальные средства фальсификации или верификация таких протоколов с
использованием современных инструментов анализа.
Объектами
исследования
являются
открытый
протокол
OAuth
и,
построенный на базе протокола авторизации OAuth, протокол аутентификации
OpenID Connect.
11
В
качестве
инструментальных
средств
исследования
выступают
программно-технические средства и методы анализа открытых протоколов.
Целью
магистерской
диссертации
является
повысить
безопасность
открытого протокола OAuth.
Основными задачами можно выделить следующие пункты:
– выбор инструментального средства для анализа открытых протоколов
OAuth и OpenID Connect;
– анализ открытого протокола OAuth;
– анализ открытого протокола OpenID Connect;
– создание метода защиты веб приложения, использующего открытые
протоколы OAuth и OpenID Connect от межсайтовой подделки запросов;
– создание метода защиты веб приложения, использующего открытый
протокол OAuth от фишинга.
Анализ безопасности открытых протоколов OAuth и, построенный на
базе протокола авторизации OAuth, протокол аутентификации OpenID Connect
позволяет выявить недостатки в спецификациях протоколов, что в свою очередь
дает возможность:
– повысить стабильности работы указанных протоколов;
– повысить
уровень
безопасности
функционирования
указанных
протоколов.
Научная новизна работы состоит в:
– разработке и анализе моделей протоколов OAuth и OpenID Connect в
среде ProVerif;
– разработке возможных предложений по устранению выявленных на этапе
анализа недостатков.
Практическая ценность работы заключается в возможности применения
разработанных моделей для дальнейшего исследования указанных протоколов, а
также для устранения возможных недостатков в рассматриваемых протоколах.
12
1 СОВРЕМЕННЫЕ ОТКРЫТЫЕ ПРОТОКОЛЫ АУТЕНТИФИКАЦИИ И
АВТОРИЗАЦИИ
1.1 Задачи аутентификации и авторизации
Объем данных, хранящихся в Интернете, быстро растет. Люди хранят все
большее количество своих данных в облаке и часто нуждаются в авторизации и
аутентификации сторонних приложений для доступа к данным.
Авторизации
OAuth
направлена
на
предоставление
открытого
и
стандартизованного протокола авторизации. Это гибкая и расширяемая структура,
которая имеет четыре разных типа
варианта применения и несколько
необязательных вариантов реализации. В результате, внедрение OAuth требует
больших знаний как спецификации OAuth, так и безопасности в Интернете.
Целевая группа Internet Engineering Task Force (IETF), отвечающая за
спецификацию OAuth, предоставила ряд мер по обеспечению безопасности для
OAuth. Кроме того, было опубликовано ряд исследований, посвященных оценке
безопасности OAuth. Однако ни один из этих ресурсов не предоставляет полную
модель, которая обеспечивает безопасную реализацию OAuth.
Традиционно аутентификация выполнялась с использованием «клиентсервер» модели, где клиент запрашивает защищенный ресурс на сервере путем
аутентификации с использованием учетных данных владельца ресурса. В этой
модели единственным способом предоставить стороннему приложению доступ к
защищенным ресурсам является передача учетных данных владельца ресурса
третьей стороне. Этот подход имеет несколько проблем и ограничений:
 приложения сторонних разработчиков должны сохранять эти учетные
данные для использования в будущем, часто в форме обычного текста, без какоголибо шифрования;
 серверы должны поддерживать аутентификацию с помощью пароля,
несмотря на то, что пароли имеют недостатки в безопасности;
 владелец ресурса не может ограничить продолжительность или объем
доступа, что дает сторонним приложениям чрезмерно широкий доступ к ресурсам;
13
 единственный способ отменить доступ у определенного клиента – это
изменить пароль, который отменяет доступ у всех клиентов.
Решение этих проблем требует дополнительных средств для авторизации и
аутентификации. OAuth и OpenID Connect – это два распространенных стандарта,
разрешающих авторизацию и аутентификацию с помощью HTTP/HTTPS.
OAuth и OpenID Connect стремятся решить проблемы модели «клиентсервер» путем введения авторизации, аутентификации и разделения ролей. В
OAuth клиенту выдается другой набор учетных данных, чем у владельца ресурса.
Вместо учетных данных владельца ресурса клиент получает токен доступа с
сервера авторизации. Токены доступа выдаются с разрешения владельца ресурса.
После выдачи клиент использует токен доступа для доступа к защищенным
ресурсам, размещенным на сервере ресурсов. OAuth изначально предназначен для
авторизации, а не для аутентификации.
А OpenID Connect, как раз наоборот, здесь идентификационный токен
используется
для
аутентификации,
сервер
ресурсов
должен
совершить
перенаправление на сервер авторизации, чтобы проверить, разрешает ли
идентификационный токен доступ к защищенному ресурсу.
Эти два стандарта обладают некоторой функциональной совместимостью.
IETF определил профиль OpenID Connect для аутентификации и OAuth для
авторизации клиентов. В контексте веб-разработки OAuth широко используется
для авторизации доступа к API-интерфейсам веб-сервисов и для Social / Single SignOn (например, Google, Twitter, Microsoft, Facebook).
1.2 Описание открытого протокола OAuth
Многие приложения имеют свою собственную систему учетных записей
(включая имена пользователей и пароли), некоторые приложения полагаются на
другие службы, чтобы проверить личность пользователей. Это называется
федеральной аутентификацией. В корпоративной ИТ-сфере приложения могут
доверять серверу Active Directory, LDAP-серверу или поставщику SAML для
аутентификации пользователей. В Интернете приложения часто доверяют
14
провайдерам OpenID (например, Google или Yahoo!) для проверки подлинности
пользователей. Существует множество преимуществ использования федеральной
аутентификации как для разработчиков приложений, так и для пользователей.
Делегированная авторизация предоставляет доступ другому лицу или
приложению доступ на выполнения действий от имени пользователя ресурса. В
OAuth это происходит следующим образом: пользователь предоставляет доступ
приложению на выполнение действий от его имени, и приложение может
выполнять только разрешенные пользователем действия.
OAuth требует регистрации приложений на сервере авторизации, чтобы
запросы API могли быть правильно идентифицированы. Хоть и протокол позволяет
регистрироваться с использованием автоматизированных средств, большинство
поставщиков API требуют ручной регистрации через заполнение формы на сайтах.
Для примера был взят сервис Яндекс. Если перейти по ссылке
https://oauth.yandex.ru/client/new,
разработчику
предоставляется
возможность зарегистрировать приложение, которое будет использовать OAuth для
авторизации пользователей. На рисунке 1.1 представлено создание приложения.
Разработчик приложения не должен открыто публиковать где-либо
свой client_id. Утечка client_id может спровоцировать "фишинговые атаки", то есть
выпуск приложений или сайтов, получающих токены авторизации от вашего
имени.
Противодействовать
(client_secret),
приложения
(client_secret).
известного
должен
этому
можно
только
разработчику
обеспечить
с
помощью
секретного
приложения.
конфиденциальность
слова
Разработчик
секретного
слова
15
Рисунок 1.1 – Создание приложения на примере сервиса Яндекс
Для того чтобы создать приложение, необходимо заполнить следующую
информацию:
1.
Название приложения – название, которое будет отображаться на
странице запроса прав доступа и в списке зарегистрированных приложений.
16
2.
Описание
приложения
(не
обязательно)
–
краткое
описание
приложение. Отображается в списке приложений, которым пользователь разрешил
доступ к своему аккаунту.
3.
Иконка приложения (не обязательно) – картинка, которая будет
отображаться в списке зарегистрированных приложений и на странице запроса
прав доступа.
4.
Ссылка на сайт приложения (не обязательно) – ссылка, которая
отображается в списке приложений, которым пользователь разрешил доступ к
своему аккаунту.
5.
Платформы – выбор платформы для которых будет доступно
приложение: iOS приложение, Android приложение или веб сервис.
6.
Callback URI – Адрес, на который пользователь возвращается после
того, как он разрешил или отказал приложению в доступе.
После этого разработчику приложения необходимо отметить галочками
доступы, к которым приложение будет иметь доступ. Это представлено на рисунке
1.2.
Рисунок 1.2 – Разрешение на доступ к адресу электронной почты, логину, имени,
фамилии и полу на примере сервиса Яндекс
17
После
регистрации
разработчика
перекидывает
на
ссылку
https://oauth.yandex.ru/client/, где отображается информация о
созданном приложение, в данном случае это: название, описание, права доступа
приложения. Кроме этого, сервис Яндекс присваивает уникальный идентификатор
(Client ID) и пароль (Client secret). На рисунке 1.3 представлено зарегистрированное
приложение.
Client ID – публично доступная строка, которая используется API сервисом
для идентификации приложения.
Client secret – пароль, который используется для аутентификации
подлинности приложения API сервиса, когда приложение запрашивает доступ к
аккаунту пользователя. Секрет клиента должен быть известен только приложению
и API.
Рисунок 1.3 – Зарегистрированное приложение TestOAuthApplication на примере
сервиса Яндекс
18
OAuth определяет несколько важных профилей клиентов.
Веб-приложение на стороне сервера. Клиент OAuth работает на веб-сервере.
Доступ к веб-приложению осуществляется владельцем ресурса (пользователем), и
приложение выполняет соответствующие вызовы API с использованием языка
программирования на стороне сервера. Пользователь не имеет доступа к
секретному ключу OAuth или к любым токенам доступа, выданным сервером
авторизации.
Клиентское приложение, работающее в веб-браузере. Клиент OAuth
работает в веб-браузере пользователя, где имеет доступ к коду приложения и / или
запросам API. Приложение может быть написано на языке программирования
JavaScript, и вставлено в веб-страницу, в качестве расширения браузера или с
использованием подключаемых технологий, таких как Flash.
Собственное приложение. Клиент OAuth, который очень схож с клиентским
приложением, которое работает в браузере, но у данного профиля имеется большой
недостаток, поскольку это установленное приложение, оно может не иметь доступа
к полным возможностям веб-браузера.
Большинство API OAuth требуют токен-держатель для авторизации
запросов. Токен-держатель – это тип токена доступа, при котором хранение
значений токенов обеспечивает доступ к защищенным ресурсам. Для вызова API
не требуется никакой дополнительной информации, такой как криптографический
ключ. Если создается серверное веб-приложение, клиентское веб-приложение или
собственное приложение, конечная цель использования OAuth одинакова:
получить токен доступа OAuth, который может использовать приложение для
выполнения запросов API от имени пользователя или самого приложения.
После получения токена доступа, токен может быть отправлен вместе с
запросом
одним
из
нескольких
способов.
Предпочтительным
способом
авторизации запросов является отправка токена доступа в заголовке HTTPавторизации:
GET /tasks/v1/lists/@default/tasks HTTP/1.1
Host: www.googleapis.com
19
Authorization: Bearer ya29.AHES6ZSzX
Заголовок авторизации является предпочтительным механизмом, потому
что:
1.
Заголовок редко регистрируется прокси-серверами и журналами
доступа к веб-серверу.
2.
Заголовок почти не кэшируется.
3.
Заголовок не сохраняется в кеше браузера при выполнении запросов от
клиента.
Каждый из профилей клиента должен быть размещен с соответствующим
набором данных протокола для получения разрешения от владельца ресурса на
доступ к данным. Основной протокол OAuth определяет четыре основных типа
варианта применения, используемых для получения авторизации, а также
определяет механизм расширения для включения дополнительных вариантов
применения открытого протокола OAuth.
Код авторизации – этот метод наиболее подходит для серверных вебприложений. После того, как владелец ресурса разрешил доступ к своим данным,
происходит перенаправление обратно в веб-приложение с кодом авторизации в
качестве параметра запроса в URL-адресе. Этот код необходимо обменять на токен
доступа клиентским приложением. Этот обмен выполняется от сервера к серверу и
требует, как идентификатора клиента, так и секретного пароля клиента, что мешает
даже владельцу ресурса получить токен доступа. Этот тип гранта также
обеспечивает долговременный доступ к API с помощью токенов обновления.
Неявный метод – этот метод является наиболее упрощенным из всех
методов и оптимизирован для клиентов, работающих в браузере. Владелец ресурса
предоставляет доступ приложению, а новый токен доступа сразу же отбирается и
передается обратно в приложение, используя хеш-фрагмент в URL-адресе.
Приложение может немедленно извлечь токен доступа из хеш-фрагмента,
например, используя JavaScript, и сделать запросы API. Этот метод не требует
промежуточного кода авторизации, но он также не предоставляет токены
обновления для долговременного доступа.
20
Учётные данные владельца ресурса – этот метод использует имя
пользователя и пароль для обмена на токен доступа OAuth. Данный метод
используется только для доверенных клиентов, таких как мобильное приложение,
написанное поставщиком API. Хоть и пароль пользователя используется клиентом,
его не нужно хранить на устройстве. После первоначальной аутентификации
необходимо сохранить только токен OAuth. Поскольку пароль не сохраняется,
пользователь может отменить доступ к приложению без изменения пароля, а токен
ограничен доступом, поэтому этот метод по-прежнему обеспечивает повышенную
безопасность при традиционной аутентификации имени пользователя и пароля.
Учетные данные клиента – этот метод позволяет приложению осуществлять
доступ к своему собственному аккаунту сервиса. Это может быть полезно,
например, когда приложение хочет обновить собственную регистрационную
информацию на сервисе или URI-перенаправления, или же осуществить доступ к
другой информации, хранимой в аккаунте приложения на сервисе, через API
сервиса.
1.2.1 Последовательность шагов веб приложения, работающего на стороне
сервера
В методе «Код авторизации» владелец ресурса сначала перенаправляется
приложением на сервер авторизации OAuth поставщика API, потом сервер
авторизации проверяет, имеет ли пользователь активный сеанс. Если да, то сервер
авторизации запрашивает доступ к данным, и после предоставления доступа
происходит перенаправление обратно в веб-приложение, а код авторизации
включается в URL адрес, как параметр:
http://www.example.com/oauth_callback?code=ABC1234
Поскольку код передается как параметр запроса, браузер отправляет его на
веб-сервер. Затем этот код авторизации обменивается на токен доступа, используя
вызов «сервер-сервер» из приложения на сервер авторизации. Этот токен доступа
используется клиентом для вызова API.
21
На рисунке 1.4 показаны шаги, которые основаны на диаграмме
спецификации.
Код авторизации следует использовать, когда:
1.
Требуется долговременный доступ.
2.
Клиент OAuth – это сервер приложений.
3.
Ответственность за вызовы API очень важна, и токен OAuth не должен
просачиваться в браузер, где у пользователя может быть доступ к нему.
Код авторизации не предоставляет токен доступа браузеру владельца
ресурса.
Вместо
этого
авторизация
выполняется
с
использованием
промежуточного «кода авторизации», который передается через браузер. Этот код
необходимо обменять на токен доступа до того, как будут сделаны вызовы к
защищенным API. Процесс обмена будет успешным только в том случае, если с
запросом передан правильный секретный пароль клиента, обеспечивающий
конфиденциальность токена доступа при условии сохранения безопасности
клиента. В отличие от «неявного» метода, эта конфиденциальность также
распространяется на владельца ресурса, то есть запросы API, сделанные с помощью
токена доступа, напрямую связаны с клиентом и его разработчиками. Самое
главное токен доступа никогда не должен отправляется через браузер, потому что
риск, что токен доступа попадет в руки злоумышленников очень высок.
Хоть и вероятность протекания токена доступа минимальна, поскольку он
не отображается в браузере, многие приложения, использующие этот метод, будут
хранить долгоживущие токены обновления в базе данных приложения или
хранилище ключей, чтобы включить «автономный» доступ к данным. Существует
дополнительный риск, когда приложение требует долговременного автономного
доступа к данным, поскольку это создает единую точку для доступа к данным,
принадлежащим многим пользователям. Этого не происходит с другими методами,
таким как метод для клиентских приложений. Даже при этом дополнительном
риске многие веб-сайты будут использовать «автономный» доступ к данным,
поскольку их архитектура приложений затрудняет взаимодействие с браузером
пользователя для получения новых токенов доступа.
22
Рисунок 1.4 – Метод «Код авторизации» по шагам
Поскольку OAuth перенаправляет пользователей на веб-сайт поставщика
API для получения авторизации, лучше всего заранее сообщить им об этом. После
того, как пользователь нажмет на ссылку, приложению потребуется отправить
браузер пользователя на страницу авторизации OAuth. Это можно сделать либо
путем отправки основного окна браузера непосредственно в конечную точку
авторизации, либо путем создания всплывающего окна. На этой странице
поставщик API представит пользователю запрос на одобрение приложения для
доступа к данным пользователя. Конечно, пользователь должен быть уже
23
авторизован для поставщика API, или пользователю будет предложено пройти
аутентификацию, прежде чем предоставить доступ к данным.
Необходимо добавить несколько параметров для запроса:
1.
Client_id – значение, предоставленное при регистрации приложения.
2.
Redirect_uri – место, куда должен быть возвращен пользователь после
одобрения доступа приложения. Значение, используемое для redirect_uri, обычно
должно быть зарегистрировано заранее у поставщика;
3.
Scope – данные, к которым обращается приложение. Обычно это
указывается как список строк с разделителями, хотя Facebook использует строки с
разделителями-запятыми. Допустимые значения для области должны быть
включены в документацию поставщика API. Область для заданий Google –
https://www.googleapis.com/auth/tasks. Если приложение также
нуждалось в доступе к Документам Google, оно указывало бы значение области
https://www.googleapis.com/auth/tasks
https://docs.google.com/feeds.
4.
Response_type – для метода «код авторизации», указывается, что
«authorization code» будет возвращен в приложение после того, как пользователь
одобрит запрос авторизации.
5.
State – уникальное значение, используемое приложением, чтобы
предотвратить межсайтовую подделку запроса (значение должно быть случайной
уникальной строкой для этого конкретного запроса, неопознанной и хранимой в
секрете у клиента).
Например:
https://accounts.google.com/o/oauth2/auth?scope=https
://www.googleapis.com/auth/androidpublisher&response_type=c
ode&redirect_uri=https://example.com&client_id=56hjjh5b3kbk
53sd&state=87423njih498
Если все параметры запроса действительны и пользователь одобряет запрос
доступа к данным, пользователь будет перенаправлен обратно в приложение по
URL-адресу, указанному как redirect_uri. Однако, если один из параметров запроса
24
недействителен, существует условие ошибки. Если есть проблема с redirect_uri,
client_id или другой информацией о запросе, сервер авторизации должен
предоставить пользователю сообщение
об
ошибке, а
не перенаправить
пользователя обратно в приложение. В случае, если пользователь (или сервер
авторизации) отклоняет запрос доступа, генерируется ответ об ошибке, и
пользователь будет перенаправлен на redirect_uri с параметром запроса с именем
error, указывающим тип ошибки как access_denied. Кроме того, сервер может
включать сообщение error_description и / или error_uri, указывающее URL-адрес
веб-страницы,
содержащий
дополнительную
информацию
об
ошибке.
Access_denied является наиболее вероятным ответом на ошибку, которое
приложение должно обрабатывать.
Когда пользователь предоставил доступ, два параметра будут включены
сервером авторизации при перенаправлении обратно в веб-приложение:
1.
Code – код авторизации, указывающий, что пользователь одобрил
запрос для состояния доступа.
2.
State – значение параметра состояния, переданного в исходном запросе
на сервер авторизации. Если значения состояния не совпадают, возможно, что
злоумышленник пытается выполнить межсайтовую подделку запроса на сайт
злоумышленника, поэтому поток OAuth не должен быть продолжен.
Например:
https://payroll.saasyapp.com/oauth2callback?code=AB23
1DEF2134123kj89&state=987d43e51a262f
Приложение должно обменять код на токен доступа OAuth для выполнения
запросов API. Если используется клиентская библиотека для OAuth, этот обмен,
как правило, происходит в рамках библиотеки. Однако, если библиотека не
используется, необходимо сделать HTTP POST-запрос. В запросе необходимо
передать следующие параметры:
1.
Code – код авторизации, переданный приложению.
2.
Redirect_uri
–
место,
зарегистрированное
первоначальном запросе к конечной точке авторизации.
и
используемое
в
25
3.
Grant_type
–
значение
authorization_code,
указывающее,
что
обменивается код авторизации на токен доступа.
Этот HTTP POST-запрос должен быть аутентифицирован с использованием
идентификатора клиента и секретного пароля клиента, полученных при
регистрации
приложения.
Существует
два
основных
способа
обработки
аутентификации запроса, определенного в спецификации: включить в заголовок
идентификатор клиента, как имя пользователя и секретный пароль клиента, как
пароль или включить идентификатор клиента и секретный пароль клиента в
качестве дополнительных параметров HTTP POST.
Примерный заголовок авторизации выглядит следующим образом:
MDAwMDAwMDA0NzU1REU0MzpVRWhrTDRzTmVOOFlhbG50UHhnUjhaT
WtpVU1nWWlJNg==
Если
запрос
правильно
аутентифицирован
и
другие
параметры
действительны, сервер авторизации выдаст и вернет токен доступа OAuth в JSONзакодированном ответе:
{
"access_token" : "ya29.AHES6ZSzX",
"token_type" : "Bearer",
"expires_in":3600,
"refresh_token":"1/iQI98wWFfJNFWIzs5EDDrSiYewe3dFqt5v
IV9ibT9"
}
Приложение теперь может обращаться к API напрямую через токен доступа.
Токен доступа и токен обновления должны постоянно храниться в секрете,
и они не должны подвергаться воздействию какого-либо пользователя, включая
владельца ресурса. Обычно токен обновления хранится безопасно в базе данных на
стороне сервера, связанной с учетной записью пользователя. Токены доступа также
могут храниться в базе данных, но они также могут быть кэшированы в сеансе на
стороне сервера для повышения производительности.
26
1.2.2 Последовательность шагов веб приложения, работающего на стороне
клиента
В этом методе токен доступа немедленно возвращается в приложение после
того, как пользователь предоставит запрашиваемую авторизацию. Промежуточный
код авторизации не требуется.
Неявный метод следует использовать, когда:
1.
Требуется только временный доступ к данным.
2.
Пользователь регулярно регистрируется у поставщика API.
3.
Клиент OAuth работает в браузере (используя JavaScript, Flash).
4.
Браузер является доверенным и нет возможности того, что токен
доступа
может
попасть
к
приложениям
с
плохой
репутацией
или
злоумышленникам.
На рисунке 1.5 показана пошаговая блок-схема, основанная на диаграмме
спецификации.
Рисунок 1.5 – Неявный метод по шагам
27
В неявном методе не используются токены обновления. Если на сервере
авторизации регулярно выполняются токены доступа, приложение должно будет
проходить через авторизацию всякий раз, когда ему нужен доступ. Некоторые
поставщики API, такие как Google, не будут перенаправлять пользователя для
доступа, если пользователь авторизовался и одобрил необходимые области.
Приложение может выполнять этот процесс обновления в фоновом режиме без
какого-либо влияния на пользовательский интерфейс.
В этом методе приложение не хранит долгоживущие токены обновления на
сервере, ограничивая экспозицию, если сервер скомпрометирован. Он также
требует, чтобы пользователь был аутентифицирован сервером авторизации
поставщика API для обновления токенов доступа на клиенте, гарантируя, что
значение токена пропущенного доступа ограничено по времени в зависимости от
реализации OAuth. Поскольку токен доступа отправляется в веб-браузер
пользователя, этот метод обеспечивает меньшую отчетность, чем код авторизации.
API-вызовы, которые, как представляется, возникли из стороннего приложения,
могут быть сделаны непосредственно самим владельцем ресурса.
Как и в случае метода, основанного на коде авторизации для серверных вебприложений, сначала нужно зарегистрировать приложение у поставщика API.
После того, как приложение зарегистрировано, необходимо перенаправить
пользователя по следующей ссылке:
https://accounts.google.com/o/oauth2/auth?response_ty
pe=token'&redirect_uri='http://photoviewer.saasyapp.com/pv/
oauth2callback.html&scope='https://www.google.com/m8/feeds/
&state=14f1jh41j4bh1
После того как пользователь одобрит доступ, всплывающее окно
перенаправит его обратно по указанному redirect_uri, а токен доступа будет
включен в хэш. Вот пример URL для этого приложения:
http://photoviewer.saasyapp.com/pv/oauth2callback.htm
l#access_token=ya29.AHES6ZSzX&token_type=Bearer&expires_in=
3600
28
После, токен доступа передается в главное окно браузера, чтобы в
дальнейшим обращаться с помощью него к API.
1.2.3 Последовательность шагов веб приложения, основанного на учетных
данных владельца ресурса
Учетных данные владельца ресурса позволяет обменивать имя пользователя
и пароль пользователя на токен доступа и, необязательно, на токен обновления.
Этот метод имеет значительно другие свойства безопасности, чем другие методы
OAuth. Основное различие заключается в том, что пароль пользователя доступен
для приложения. Это требует доверия пользователя приложению. На рисунке 1.6
показана пошаговая блок-схема, основанная на диаграмме спецификации.
Рисунок 1.6 – Метод «учетные данные владельца ресурса» по шагам
Поскольку пароль владельца ресурса открыт для приложения, этот метод
следует использовать редко. Он рекомендуется только для официальных
приложений, выпущенных поставщиком API, а не для более широких сторонних
сообществ разработчиков. Если пользователю предлагается ввести пароль в
29
официальные приложения, он может привыкнуть к этому и стать уязвимым для
попыток фишинга другими приложениями.
Хоть и приложение имеет доступ к паролю владельца ресурса, все же есть
некоторые преимущества безопасности для использования этого метода по
сравнению с аутентификацией вызовов API с именем пользователя и паролем. При
обычной авторизации приложение должно иметь непрерывный доступ к паролю
пользователя, чтобы совершать вызовы API. Также требуется, чтобы пользователь
менял свой пароль и повторно вводил новый пароль во все приложения, которые
его требуют, если пользователь больше не хочет, чтобы приложение получало
доступ к своим данным. Однако, если используется логин и пароль владельца
ресурса OAuth, для приложения требуется только один раз доступ к учетным
данным пользователя: при первом использовании, когда учетные данные
обмениваются на токен доступа. Это означает, что приложение не требует
сохранения этих учетных данных в приложении или на устройстве.
Пользовательский интерфейс для этого метода идентичен обычным
запросам доступа на основе пароля. Приложение запрашивает у пользователя имя
и пароль, и пользователь предоставляет информацию. Затем приложение
выполняет запрос на стороне сервера авторизации поставщика API, без каких-либо
изменений интерфейса пользователя. Если поставщик API не выдаст refresh_token,
а выданный access_token недолговечен, приложение скорее всего сохранит имя
пользователя и пароль для будущих попыток аутентификации.
Первый шаг, необходимо, чтобы пользователь предоставил свои учетные
данные для приложения. Процесс обмена учетными данными на токен доступа
очень похож на обмен кода авторизации на токен доступа в методе «код
авторизации». Необходимо сделать HTTP POST-запрос на сервере авторизации,
предоставляя учетные данные и информацию о клиенте.
Требуемые параметры для POST запроса:
1.
Grant_type – указывается как «password» для этого метода.
2.
Scope – данные, к которым обращается приложение.
3.
Client_id – значение, предоставленное при регистрации приложения.
30
4.
Client_secret
–
значение,
предоставленное
при
регистрации
приложения. Хотя имя этого параметра подразумевает, что это значение является
секретным, иногда это необходимо поставщикам API для не конфиденциальных
клиентов, таких как мобильные приложения. В этих случаях значение на самом
деле не является секретом, поскольку оно может быть обнаружено пользователями
приложения.
5.
Имя пользователя – имя пользователя, предоставленное владельцем
ресурса, закодированное как UTF-8.
6.
Пароль
–
пароль,
предоставленный
владельцем
ресурса,
закодированный как UTF-8.
Пример запроса через HTTP-клиент командной строки curl:
сurl -d "grant_type=password"\-d
"client_id=3MVG9QDx8IKCsXTFM0o9aE3KfEwsZLvRt"\-d
"client_secret=4826278391389087694"\-d
"username=ryan%40ryguy.com"\-d
"password=_userspassword__userssecuritytoken_"\
Если
предоставленные
пользователем
учетные
данные
успешно
аутентифицированы, сервер авторизации OAuth вернет ответ приложения / json,
содержащий токен доступа:
{
"instance_url":"https://na12.salesforce.com",
"signature":"Q2KTt8Ez5dwJ4Adu6QttAhCxbEP3HyfaToNI",
"access_token":"00DU0000000Io8r!AQxU2fmKH07QiPEGIX"
}
Параметры ответа на запрос:
1.
Access_token – токен доступа, используемый для доступа к API от
имени пользователя, предоставившего свои учетные данные. Это единственный
требуемый элемент в ответе.
2.
Instance_url – префикс URL, который клиентское приложение должно
использовать для доступа к API.
31
3.
Signature – подпись, используемая для проверки того, что URL-адрес
идентификации не был изменен с момента отправки с сервера.
Поскольку токен доступа OAuth, выданный потоком авторизации,
представляет собой простой параметр-носитель, такой как токены доступа,
представленные в других, его можно использовать аналогичным образом.
Необходимо просто предоставить токен доступа через заголовок HTTPавторизации или значение параметра запроса, в зависимости от того, какой
поставщик API используется.
1.2.4 Последовательность шагов веб приложения, основанного на учетных
данных клиента
Большинство потоков OAuth предназначены для обработки делегированной
авторизации, когда владелец ресурса предоставляет доступ приложению, которое
в свою очередь предоставляет доступ к данным. Однако бывают случаи, когда
клиент сам владеет данными и не нуждается в делегированном доступе владельца
ресурса, или делегированный доступ уже предоставлен приложению не типичного
потока OAuth.
Этот метод показан на рисунке 1.7.
Рисунок 1.7 – Метод «учетные данные клиента» по шагам
Facebook реализовал этот поток для своих приложений, чтобы иметь
возможность выполнять вход в приложение. Вход для приложений необходим для
определенных вызовов API Facebook, включая возможность получать статистику
приложений и демографию пользователей из службы App Insights.
32
Для аутентификации клиент может передать идентификатор клиента и
секретный пароль клиента на сервер авторизации в качестве параметров POST –
токен доступа или использовать базовый заголовок HTTP. Сервер авторизации
также может аутентифицировать клиента, используя другие механизмы, такие как
пара открытого / закрытого ключа, аутентификация клиента SSL / TLS и другие
механизмы.
В зависимости от конкретного варианта использования потока учетных
данных клиента единый набор учетных данных для клиента может обеспечить
доступ к большому количеству данных. Чем больше данных имеет один набор
учетных данных, тем больше риск, что учетные данные будут скомпрометированы.
Крайне важно, чтобы учетные данные, используемые для аутентификации клиента,
были конфиденциальными. В идеале эти учетные данные должны будут регулярно
меняться.
Приложение должно запросить токен доступа с сервера авторизации,
аутентифицируя запрос с учетными данными клиента.
URL запрос, с помощью которого можно обратиться к API facebook:
https://graph.facebook.com/oauth/access_token
Требуемые параметры POST:
1.
Grant_type – указано как «client_credentials» для этого потока.
2.
Client_id – значение, предоставленное при регистрации приложения.
3.
Client_secret
–значение,
предоставленное
при
регистрации
приложения.
Пример запроса через HTTP-клиент командной строки curl:
curl-d"grant_type=client_credentials\
&client_id=2016271111111117128396\
&client_secret=904b98aaaaaaac1c92381d2"\
https://graph.facebook.com/oauth/access_token
Если учетные данные клиента успешно завершены, токен доступа
возвращается клиенту:
access_token=2016271111111117128396|8VG0riNauEzttXkUXBtUbw
33
Поскольку токен доступа OAuth, выданный потоком учетных данных,
является токеном-носителем, таким как токены доступа, предусмотренные в
других потоках, его можно использовать аналогичным образом. Нужно
предоставить токен доступа через заголовок HTTP-авторизации или значение
параметра запроса, в зависимости от того, какой поставщик API используется.
1.3 Описание открытого протокола OpenID Connect
Почти каждое веб-приложение предлагает пользователям создать учетную
запись и войти в систему. Чтобы создать учетную запись, пользователям
предлагается указать свое имя, адрес электронной почты, пароль и подтверждение
пароля. Это не только требует больших усилий для пользователя, но также создает
проблемы безопасности, так как пользователи часто создают один и тот же пароль
на нескольких сайтах, а сайты не обеспечивают надлежащую защиту этих учетных
данных.
OpenID предназначен для того, чтобы осуществить федеративную
идентификацию,
одинаковыми
где
пользователи
учетными
данными
могут
в
проходить
нескольких
аутентификацию
веб-приложениях.
с
Как
пользователи, так и веб-приложения доверяют поставщикам услуг, таким как
Google, Yahoo! и Facebook, хранение информации и аутентификации от имени
приложения. Это устраняет необходимость того, чтобы каждое веб-приложение
создавало собственную систему аутентификации, и это значительно облегчает и
ускоряет доступ пользователей к сайтам в Интернете.
OpenID Connect – это версия OpenID следующего поколения. В разработке
OpenID Connect учтены две ключевые концепции:
1.
Передача разрешения на доступ к информации на сайт очень похожа на
передачу делегированного доступа к данным пользователя. Разработчикам не
нужно использовать разные протоколы для этих двух разных случаев
использования, потому что многие разработчики должны обрабатывать их в своих
приложениях.
34
2.
Спецификация должна быть модульной, обеспечивающей соответствие
спецификации, не требуя применения автоматических открытий, ассоциаций и
других сложных битов, включенных в предыдущие версии OpenID.
OpenID Connect состоит из трех основных этапов:
1.
Приложение запрашивает авторизацию OAuth для одной или
нескольких областей OpenID Connect (openid, profile, email, address), перенаправляя
пользователя к поставщику услуг.
2.
браузер
После того как пользователь одобрит запрос авторизации OAuth, вебпользователя
перенаправляется
его
обратно
в
приложение
с
использованием традиционного метода OAuth. Приложение отправляет запрос на
адрес проверки. Этот адрес возвращает идентификатор пользователя, а также
другие данные, которые должны быть проверены клиентом для обеспечения
достоверной аутентификации.
3.
Если клиенту требуется дополнительная информация о пользователе,
например, полное имя пользователя, фотография и адрес электронной почты,
клиент может отправлять запросы для получения дополнительной информации.
OpenID Connect построен поверх OAuth и разработан как модульная
спецификация. При аутентификации OpenID Connect существует дополнительный
токен OAuth: ID токен. ID токен представляет идентификатор аутентифицируемого
пользователя. Это отдельный токен из токена доступа, который используется для
извлечения информации профиля пользователя или других пользовательских
данных, запрашиваемых в течение одного и того же метода авторизации. Токен ID
это JSON Web Token (JWT), который представляет собой цифровую подпись и /
или зашифрованное представление идентификатора пользователя, установленного
поставщиком
идентификации.
Вместо
того,
чтобы
использовать
криптографические операции для проверки JSON Web Token, его можно
рассматривать как строку и передавать в конечную точку для интерпретации.
Меры безопасности, необходимые для аутентификации, сильно отличаются
от требований к авторизации из-за возможности повторных атак. Атаки повторного
35
использования происходят, когда учетные данные отправляются несколько раз для
вредоносных целей.
Необходимо предотвратить два основных типа повторных атак:
1.
Злоумышленник захватывает учетные данные пользователя OAuth при
входе на сайт и использует их позже на одном сайте.
2.
Разработчик приложения – злоумышленник, использующий токен
OAuth, был выдан для входа во вредоносное приложение, чтобы олицетворять
пользователя в другом приложении.
Спецификация OAuth требует, чтобы адрес OAuth и API были доступны
через SSL / TLS для предотвращения атак посредника.
Предотвращение попыток разработчиков-злоумышленников от повторного
использования учетных данных OAuth, полученное их приложением для
олицетворения одного из своих пользователей в другом приложении, требует
решения, специфичного для OpenID Connect. Это решение – адрес идентификатора
проверки. Адрес идентификатора проверки используется для проверки того, что
учетные данные, выданные поставщиком OAuth, были выданы правильному
приложению.
Рекомендуется,
чтобы
все
разработчики
использовали
адрес
идентификатора проверки или декодировали токен JSON Web для проверки
утвержденных идентификаторов, хотя это не является строго необходимым.
Метод веб-приложения на стороне сервера, реализованный в соответствии
со спецификацией, выдает только код авторизации через веб-браузер пользователя.
Веб-приложение никогда не должно принимать токен доступа или токен
идентичности непосредственно из браузера. Токен доступа и токен идентификации
извлекаются путем обмена кода авторизации в запросе «сервер-сервер». Поскольку
для этого обмена требуется, чтобы вызов «сервер-сервер» был аутентифицирован
с идентификатором клиента и секретом клиента приложения, для которого был
выдан код авторизации, служба токена OAuth, естественно, предотвратит
случайное использование приложения с использованием кода авторизации,
выданного другому приложение.
36
В качестве альтернативы, метод веб-приложений на стороне клиента выдает
токен доступа и токен идентичности непосредственно в приложение через браузер
с использованием хэш-фрагмента. Токен доступа и токен идентичности часто
отправляются на сервер с использованием JavaScript для аутентификации
пользователя. В этом случае веб-сервер должен либо криптографически проверить
токен идентификатора, либо вызвать идентификатор проверки, чтобы убедиться,
что он был выдан правильному приложению. Это называется проверка токена.
Процесс авторизации пользователя для OpenID Connect почти идентичен
процессу авторизации для любого API с поддержкой OAuth. Можно использовать
неявный поток на стороне или поток веб-приложений на стороне сервера. Как и
при любом использовании этих потоков, клиент создает URL-адрес, указывающий
на адрес авторизации OAuth, и перенаправляет пользователя на этот URL-адрес.
Передаются следующие параметры: client_id, redirect_uri, scope, response_type,
nonce.
Nonce – уникальное значение, используемое приложением для защиты от
межсайтовой подделки запросов.
Ниже приведен пример полного URL-адреса авторизации с использованием
неявного потока на стороне клиента:
https://accounts.example.com/oauth2/auth?
scope=openid+email&
nonce=53f2495d7b435ac571&
redirect_uri=https3A2F2Foauth2demo.appspot.com%2Foaut
hcallback&
response_type=id_token+token&
client_id=7535606811452ik2j3snsvbs80ijdi8.apps.googleusercontent.com
После того как пользователь одобрит запрос на аутентификацию, он будет
перенаправлен обратно на redirect_uri. Поскольку этот запрос использует неявный
поток, перенаправление будет включать токен доступа, который может
использоваться с адресом для получения информации о профиле пользователя.
37
Кроме того, и для OpenID Connect, перенаправление также будет включать
идентификатор id_token, который может быть отправлен на адрес, чтобы получить
идентификатор пользователя.
Пример перенаправления:
https://oauth2demo.appspot.com/oauthcallback#
access_token=ya29.AHES6ZSzX
token_type=Bearer&
expires_in=3600&
id_token=c3MiOiJhY2NvdW50cy5nb29nbGUuY29tIiwiY
Затем клиенту необходимо проанализировать соответствующие параметры
из хеш-фрагмента в URL-адресе и вызвать адрес ID для проверки ответа.
Адрес идентификатора проверки существует для проверки id_token,
возвращенного вместе с OAuth, гарантируя, что он предназначен для правильного
клиента и используется клиентом для начала аутентифицированного сеанса. Если
эта проверка выполнена неправильно, клиент становится уязвимым для повторных
атак.
Пример запроса:
https://accounts.example.com/oauth2/tokeninfo?id_toke
n=eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJhY2NvdW50cy5nb29nbGUuY29t
IiwiY
Пример ответа:
{
"iss" : "https://accounts.example.com",
"user_id" : "113487456102835830811",
"aud":"7535606811452ik2j3snsvbs80ijdi8.apps.googleuse
rcontent.com",
"exp" : 1311281970,
"nonce" : 53f2495d7b435ac571
}
38
Хоть и адрес идентификатора проверки вернет уникальный идентификатор
для аутентификации пользователя для приложения, многие приложения требуют
дополнительной информации, такой как имя пользователя, адрес электронной
почты, фотография профиля или дата рождения. Эта информация профиля может
быть возвращена адресом пользовательской информации. Адрес пользовательской
информации является стандартным REST API с авторизацией OAuth с ответами
JSON. Как и при доступе к любому другому API с использованием OAuth, токен
доступа может передаваться либо как заголовок авторизации, либо как параметр
запроса URL.
Пример запроса пользовательской информации с ответом:
{
«user_id»: «3191142839810811»,
«name»: «Example User»,
«given_name»: «Example»,
«family_name»: «User»,
«email»:«[email protected]»,
"verified": true,
"profile": "http://profiles.example.com/user",
"picture":
"https://photos.profiles.example.com/user/photo.jpg",
"gender ":" женщина ",
" день рождения ":" 1982-02-11 ",
" locale ":" en-US "
}
39
2 ИССЛЕДОВАНИЕ ОТРЫТЫХ ПРОТОКОЛОВ OAUTH И OPENID
CONNECT
2.1 Анализ и выбор инструментального средства для анализа открытых
протоколов OAuth и OpenID Connect
Automated Validation of Internet Security Protocols and Applications (AVISPA)
– инструмент для автоматический проверки безопасности интернет протоколов и
приложений. Этот инструмент обеспечивает модульный и выразительный
формальный язык для определения протоколов и их свойств безопасности. Также
предусмотрена возможность интеграции различных дополнительных методов
автоматического анализа протоколов. Разработчики данного программного
средства считают, что AVISPA является самым современным средством анализа
протокола безопасности в Интернете, поскольку, ни один другой инструмент не
имеет такого же уровня охвата и надежности при одинаковой производительности
и масштабируемости.
Инструмент AVISPA предоставляет:
1.
Модульный и выразительный формальный язык для специфических
свойств и безопасности протоколов – High-Level Protocol Specification Language
(HLPSL);
2.
Возможность интегрировать различные дополнительные методы,
которые реализуют автоматический анализ, начиная от фальсификации протокола
(путем поиска атаки) и заканчивая методами проверки на основе абстракции для
бесконечного числа сеансов.
На рисунке 2.1 представлена архитектура инструмента AVISPA.
40
Рисунок 2.1 – Архитектура инструмента AVISPA
Пользователь
взаимодействует
с
инструментом,
указав
проблему
безопасности (протокол в паре со свойством безопасности, которого, как
ожидается, достигнет) на языке HLPSL. HLPSL – выразительный, модульный,
основанный на ролях формальный язык, который включает в себя описание схем
управления
потоками,
структур
данных,
различных
криптографических
операторов и их алгебраических свойств, альтернативных моделей противника, а
также сложных свойств безопасности. Эти функции позволяют указывать
протоколы в HLPSL, не прибегая к конкретным методам, чтобы сначала упростить
протоколы. AVISPA автоматически переводит (через конвертацию HLPSL2IF)
определенную
пользователем
проблему
безопасности
в
эквивалентную
спецификацию, написанную на формальном языке в промежуточный формат
(Intermediate Format (IF)). Спецификация IF описывает систему с бесконечным
числом состояний, доступную для формального анализа: спецификации IF
автоматически поступает на вход инструмента AVISPA, которые реализуют
различные методы поиска соответствующей системы перехода бесконечного числа
41
состояний для состояний, которые представляют атаки на предполагаемые
свойства протоколов.
Текущая версия инструмента объединяет четыре встроенных метода для
анализа: On-the-fly Model-Checker (OFMC), the Constraint-Logic-based Attack
Searcher
(CL-AtSe),
SAT-based
Model-Checker
(SATMC)
и
TA4SP.
Все
вышеописанные скрипты инструмента AVISPA анализируют протоколы в
соответствии с предположениями совершенной криптографии и сообщения
протокола обмениваются по сети, находящейся под контролем злоумышленника.
То есть методы анализируют протоколы, рассматривая стандартную независимую
по протоколу асинхронную модель активного злоумышленника, который
управляет
сетью,
но
не
может
взломать
криптографию;
в
частности,
злоумышленник может перехватывать сообщения и анализировать их, если у него
есть соответствующие ключи для расшифровки, и он может генерировать
сообщения из своих знаний и отправлять их под любым именем стороны.
После завершения каждый скрипт выводит результат своего анализа с
использованием
общего
и
точно
определенного
выходного
формата,
определяющего, была ли решена проблема (дается описание рассматриваемой цели
протокола или, в случае ее нарушения, соответствующие следы атаки), или по
какой-то причине проблема не была решена требуемым исходным кодом.
Инструмент AVISPA был разработан для удобства использования ИТспециалистами, инженерами и разработчиками протоколов, работающих в
промышленности или организациях по стандартизации. Таким образом инструмент
AVISPA выгружается как единый «пакет», который будет установлен на локальных
компьютерах пользователей, а также удаленный инструмент, который может быть
использован пользователями в сети интернет, благодаря веб-графическому
интерфейсу, который поддерживает редактирование спецификации протокола и
позволяет пользователю выбирать, настраивать и выполнять различные скрипты.
Используя интерфейс, пользователь может легко загрузить спецификацию
протокола из тех, которые содержатся в библиотеке AVISPA, или написать
спецификацию самостоятельно и вызвать один или все имеющиеся скрипты. Также
42
доступен режим XEmacs для редактирования спецификаций протокола. В случае
обнаружения атаки трассировка атаки выводится как в ASCII, так и в графическом
формате, используя диаграммы последовательности сообщений, которые могут
отображаться в новом окне или выводиться в файл постскриптума. Интерфейс
имеет специализированные меню как для начинающих пользователей (базовый
режим), так и для опытных пользователей (экспертный режим), как показано на
рисунке 2.2 и на рисунке 2.3 соответственно. В частности, на рисунке 2.3 показана
часть спецификации протокола H.530 (в главном окне интерфейса и в окне XEmacs)
и диаграммы последовательности сообщений трассировки атаки, обнаруженной
инструментом AVISPA при анализе протокола.
Рисунок 2.2 – Инструмент AVISPA в базовом режиме
43
Рисунок 2.3 – Инструмент AVISPA в экспертном режиме
Automatic Cryptographic Protocol Verifier (ProVerif) – инструмент для
автоматического
Поддержка
анализа
предоставляется
безопасности
криптографических
криптографическими
протоколов.
примитивами,
включая:
симметричное и асимметричное шифрование, цифровые подписи, хэш-функции,
бит-обязательство и не интерактивные доказательства нулевого знания. ProVerif
способен доказывать свойства достижимости, утверждения соответствия и
наблюдательную эквивалентность. Эти возможности особенно полезны для
компьютерной безопасности, поскольку они позволяют анализировать свойства
секретности и аутентификации. Кроме того, в текущей версии появились новые
свойства, такие как конфиденциальность, прослеживаемость и проверяемость.
Анализ протокола рассматривается в отношении неограниченного количества
44
сеансов и неограниченного пространства сообщений. Кроме того, инструмент
способен к восстановлению атаки: когда свойство не может быть доказано, ProVerif
пытается восстановить трассировку выполнения, которая фальсифицирует
требуемое свойство. Также данный инструмент способен доказывать свойства
достижимости, утверждения соответствия и наблюдательную эквивалентность.
ProVerif - это инструмент командной строки, который может быть выполнен
с использованием синтаксиса: ./proverif [options] (filename), где ./proverif – файл
ProVerif, [filename] – это файл, который поступает на анализ инструменту ProVerif,
и параметры командной строки [options]. ProVerif может обрабатывать входные
файлы, закодированные на нескольких языках. Pi-исчисление в настоящее время
считается самым современным, и файлы такого рода обозначаются расширением
файла .pv.
Pi-исчисление является математической моделью процессов, взаимосвязи
которых меняются по мере их взаимодействия. Основным вычислительным шагом
является передача связи между двумя процессами. Получатель может затем
использовать ссылку для дальнейшего взаимодействия с другими сторонами. Это
делает исчисление подходящим для систем моделирования, где доступные ресурсы
изменяются со временем. Также обеспечивается значительная выразительная сила,
поскольку понятия доступа и ресурсов лежат в основе теории параллельных
вычислений.
Визуализация структуры ProVerif представлена на рисунке 2.4, где показано
как ProVerif принимает в качестве входных данных: модель криптографического
протокола (описанная с использованием применяемого синтаксиса Pi-исчисления)
и свойства безопасности, которые необходимо доказать. Свойства безопасности
моделируются как выводимые запросы. Затем входная информация автоматически
преобразовывается в набор «Хорновских условий», которые позже подвергаются
алгоритму разрешения. Также можно моделировать криптографические протоколы
с помощью «Хорновских условий» с самого начала. Инструмент опирается на то,
что
перевод
в
«Хорновские
условия»
является
приблизительным.
Приблизительным означает, что если атака существует в криптографическом
45
протоколе, то она также существует в приближении, но является неполной,
поскольку, если атака обнаружена в приближении, она не гарантирует, что она
также существует в криптографическом протоколе.
Рисунок 2.4 – Структура инструмента ProVerif
Условия Хорна представляют собой набор предикатов, объединенных
логическим или операционным (с не более чем одним неотрицательным)
литералом. Он определяется как: F1 ∧ ... ∧ Fn ⇒ F (≡ ¬ F1 ∨ ... ∨ ¬ Fn ∨ F), где n ≥ 0
и F - единственный не отрицаемый литерал, который также известен как факт,
предыдущее заданное условие Хорна означает, что если все факты Fi (для i = 1, ...,
46
n) истинны, то F также верно. Здесь факт F = p (M1, ..., Mn) показывает свойство
сообщений Mi (для i = 1, ..., n), а p обозначает предикаты. Основным предикатом,
используемым в условиях Хорна, является атакующий (M), который представляет
собой факт, что «злоумышленник знает термин M». M представляет собой
сообщения, которыми обмениваются участники протокола. Этот предикат можно
использовать, чтобы моделировать действия участников противников и участников
протокола.
Эти условия Хорна, полученные автоматическим переводом, представляют
собой потенциальные знания атакующего, его вычислительные способности и сам
протокол.
ProVerif
выполняет
так
называемый
алгоритм
разрешения
с
использованием полученных условий Хорна, чтобы проверить выводимость
фактов.
Когда
инструмент
проверяет,
может
ли
быть
получен
факт,
противоречащий требуемому свойству безопасности, он находит атаку. В этом
случае ProVerif выводит значение true, а также отображает некоторые действия,
которые атакующий может предпринять, чтобы разрушить требуемое свойство
безопасности. Однако, когда факт, противоречащий требуемому свойству
безопасности, не может быть выведен, выводится ложное утверждение, чтобы
сказать, что атаки нет. ProVerif не всегда заканчивается, и он также может быть
неполным (он может генерировать ложную атаку). Аппроксимация, используемая
при переводе в условия Хорна, может вызвать ложную атаку, это означает, что
вывод факта может также соответствовать ложной атаке в протоколе. Бесконечный
цикл, генерируемый условий Хорна, может привести к прерыванию ProVerif.
Однако два последних результата (без прерывания и ложной атаки) ProVerif редко
бывают на практике.
Как указано выше, ProVerif может проверить свойства секретности и
аутентификации. Доказательство секретности – это самая основная возможность
инструмента. Чтобы проверить секретность термина M, ProVerif пытается
проверить, что состояние, в котором термин M известно противнику, недостижима.
Аутентификация может быть определена с помощью утверждений соответствия.
Они используются для фиксации отношений между событиями, которые могут
47
быть выражены в форме «если какое-либо событие было выполнено, то другое
событие ранее было выполнено».
Модель протокола в ProVerif с типовым вариантом прикладного Piисчисления в качестве входного языка состоит из трех частей: объявления,
макросов процесса и основного процесса.
Объявления
включают
функции,
описывающие
криптографические
примитивы, свойства безопасности и типы пользователей. Функции делятся на две
категории: конструкторы и деструкторы. Конструкторы служат для создания
условий. Таким образом, можно представлять конструкторские приложения в виде:
f (M1, M2 ... Mk). Термины используются для моделирования сообщений между
участниками протокола. Они построены с использованием имен, переменных,
кортежей терминов, конструкторов и деструкторов, определенных в объявлениях.
Комбинированные вместе, конструктор и деструктор используются для захвата
связи между криптографическими примитивами. В качестве типичных примеров
для конструктора и деструктора рассматривается шифрование и дешифрование,
соответственно. ProVerif использует ключевое слово [private], чтобы объявить, что
злоумышленники не знают.
Процессы определяются с помощью макросов процесса. Процессы в этой
грамматике обозначаются как P, Q. Нулевой процесс ничего не делает. Репликация
P определяет неограниченное количество копий процесса P параллельно.
Ограничение имени new n: t; P создает новое имя n (типа t), а затем выполняет P.
Условное задается в терминах let. Входной процесс в (M, x: t); P вводит сообщение
на канал M, а затем он запускает P с переменной x. Выходной процесс (M, N); P
выводит сообщение N на канал M, а затем запускает P. Каждый участник протокола
моделируется как процесс. Некоторые вспомогательные события используются для
указания свойств безопасности, не влияя на поведение процесса.
Существуют три строки запроса:
1)
запрос злоумышленника: <сообщение>. запрашивает секретность
<сообщения>. Если злоумышленник находит способ узнать <сообщение>, запрос
терпит неудачу;
48
2)
query ev: <event1> ==> ev: <event2>. Происходит запрос:
произошло ли событие event <event1> раньше, чем событие <event2>;
3)
query evinj: <event1> ==> ev: <event2>. Этоn запрос
требует, чтобы было как минимум столько случаев <event2>, сколько <event1>.
Обычно предполагается, что процессы выполняются в присутствии
противника, который сам по себе является процессом в исчислении, и поэтому ему
разрешено выполнять те же действия, что и любому другому процессу.
Макросы процесса состоят из определений подпроцессов, где каждый
подпроцесс представляет собой последовательность событий. Подпроцесс P может
быть определен с использованием макросов вида: let R (x1, ..., xn) = P, где R - имя
макроса, а x1, ..., xn - свободные переменные P.
TAMARIN
PROVER
–
мощный
инструмент
для
символьного
моделирования и анализа протоколов безопасности. В качестве входной
информации используется модель протокола безопасности, определяющая
действия агентов, выполняющих протокол в разных ролях (например, инициатор
протокола, ответчик и доверенный сервер ключей), спецификация противника и
свойства
протокола.
Кроме
этого,
Tamarin
можно
использовать
для
автоматического построения доказательства, когда экземпляры ролей протокола
чередуются параллельно, вместе с действиями противника, протокол всё равно
выполняет свои заданные свойства.
Tamarin предоставляет общую поддержку моделирования и объяснения о
безопасности протоколов. Протоколы и злоумышленники определяются с
использованием
выразительного
языка,
основанного
на
многократном
перезаписывании правил. Эти правила определяют систему переходов, состояния
которых состоят из символьных представлений знаний противника, сообщений в
сети, информации о значениях и состояниях протокола. Злоумышленник и
протокол взаимодействуют путем создания и обновления сетевых сообщений.
Tamarin
также
поддерживает
эквациональную
спецификацию
некоторых
криптографических операторов, таких как Диффи Хеллман и билинейных пары.
49
Свойства безопасности моделируются как свойства трассировки, которые
проверяются системой переходов.
Tamarin обеспечивает два способа построения доказательств. Имеется
эффективный, полностью автоматизированный режим, который сочетает в себе
дедукцию и экваториальное мышление с эвристикой, чтобы вести поиск
доказательств.
Если
автоматический
поиск
доказательств
инструмента
завершается, он возвращает либо доказательство истинности (для неограниченного
количества
экземпляров
ролей
и
новых
значений),
либо
контрпример,
представляющий атаку, которая нарушает указанное свойство. Однако, поскольку
правильность протоколов безопасности является неразрешимой проблемой,
инструмент не может завершаться при заданной проверке. Следовательно,
пользователям, возможно, придется прибегнуть к интерактивному режиму
Tamarin, чтобы исследовать состояния доказательств, проверить графики атаки и
легко комбинировать руководство по ручному доказательству с автоматическим
поиском доказательств.
Формальное
эквациональной
обоснование
теории
E,
терминов
определяющей
инструмента
Tamarin:
криптографические
для
операторы,
многонаправленную систему перезаписи R, определяющую протокол, и формулу
φ, определяющую свойство трассировки, Tamarin может либо проверить
справедливость, либо выполнимость φ для трассировки R по модулю E. Как
обычно, справедливость проверка сводится к проверке выполнимости отрицания
формулы.
Здесь
решение
ограничения
используется
для
выполнения
исчерпывающего, символьного поиска исполнений с удовлетворительными
трассировками. Условиями поиска являются системы ограничений. Например,
ограничение может выражать, что в процессе выполняется какой-то этап
многоадресной перезаписи, или один шаг выполняется перед другим шагом. Также
имеется возможность напрямую использовать формулы в качестве ограничений,
чтобы выразить, что какое-то поведение не выполняется при выполнении.
Приложения
ограничения
правил,
такие
как
упрощения
или
различия,
соответствуют инкрементному построению удовлетворяющей трассировки. Если
50
никакие другие правила не могут быть применены и не будет найдена
удовлетворительная трассировка, удовлетворительный трассировки не существует.
Для символьных рассуждений используется свойство конечного варианта, чтобы
уменьшить рассуждение по модулю E относительно R до рассуждения по модулю
AC по отношению R.
Входная информация инструмента: Tamarin принимает название файла
теории в командной строке, который определяет теорию экванов, моделирующую
сообщения протокола, многозадачную систему перезаписи для моделирования
протоколов, и набор лемм, определяющих желаемые свойства протокола. Для
примера анализа был взял протокол Diffie-Hellman и для того, чтобы
проанализировать безопасность данного протокола, используется файл теории,
который состоит из следующих частей.
Теория равенств. Чтобы указать набор сообщений протокола, используется:
builtins: diffie-hellman
functions: mac/2, g/0, shk/0 [private]
Это способствует экспоненции Diffie-Hellman(DH) и определяет три
функциональных символа. Поддержка экспоненциальности DH определяет
оператор
^,
который
удовлетворяет
уравнению
(g^x^y=(g^y^x
и
дополнительным операторам. Используется фукнция mac/2 для моделирования
кода аутентификации сообщения (MAC), константы g для моделирования
генератора группы DH и константы shk для моделирования общего секретного
ключа, который объявляется как закрытый и, следовательно, не выводится
непосредственно. Также имеется возможность спаривания и проецирования с
использованием <_,_>, fst и snd предоставляются по умолчанию.
Протокол. Определение протокола состоит из трех («помеченных») правил
многократной перезаписи. Эти правила имеют последовательности фактов в левой
части, метки в правой части. Факты имеют вид F (t1, ..., tk) для символа факта F и
термов ti. Правила протокола используют фиксированные унарные символы
символов Fr и In для получения новых имен (уникальных и неопределяемых
51
констант) и сообщений, полученных от сети. Чтобы отправить сообщение в сеть,
они используют фиксированный унарный символ факта Out.
В первом правиле моделируется создание нового потока протокола tid,
который выбирает новый показатель x и отправляет out g x, конкатенированный с
MAC этого значения и идентификаторы участников:
rule Step1: [ Fr(tid:fresh), Fr(x:fresh) ] −[
[
Out(<g^(x:fresh),
mac(shk,
]→
<g^(x:fresh),
A:pub, B:pub>)>)
, Step1(tid:fresh, A:pub, B:pub, x:fresh) ]
В этом правиле используется аннотации :fresh и :pub, для гарантии того, что
соответствующие переменные будут созданы только с использованием новых и
общедоступных имен. Экземпляр правила Step1 перезаписывает состояние,
используя два Fr-факта, чтобы получить новые имена tid и x и сгенерировать факт
Out с отправленным сообщением и фактом Step1, обозначающим, что данный
поток завершил первый шаг с заданными параметрами. Аргументы Step1
обозначают
идентификатор
потока,
актера,
предполагаемого
партнера
и
выбранного экспонента.
Второе правило моделирует второй шаг протокола:
rule
Step2:
[
Step1(tid,
A,
B,
x:fresh),
In(<Y,
mac(shk, <Y, B, A>)>) ]
−[ Accept(tid, Y^(x:fresh)) ]→ []
Здесь, кроме факта, который должен был быть создан на более раннем шаге
Step1 используется как дополнительный факт In. Факт In использует сопоставление
образцов для проверки MAC. Соответствующая метка Accept (tid, Y^(x: fresh))
означает, что поток tid принял сеансовый ключ Y^(x: fresh).
В третьей модели правил раскрывают общий секретный ключ противнику:
rule RevealKey: [] − [ Reveal() ] → [ Out(shk) ]
Постоянный shk будет отображет в сети и метка Reveal () гарантирует, что
трассировка отобразит, если это служится.
52
Набор
протокольных
трассировок
определяется
посредством
мультимножественной перезаписи (по теории равенств) с этими и встроенными
правилами для создания новых имен, приема сообщений противником, вывода
сообщений и отправки сообщения противником, что можно наблюдать
посредством фактов form K (m).
Свойства. Определяются требуемые свойства безопасности протокола как
свойства трассировки. Поэтому метки правил протокола должны содержать
достаточно информации для описания этих свойств. В Tamarin свойства указаны
как леммы, которые затем сбрасываются или не учитываются инструментом.
lemma Accept_Secret:
∀ i j tid key. Accept(tid,key)@i & K(key)@j ⇒ ∃ l.
Reveal()@l & l < i
Лемма определяет количественно по времени i, j, l и сообщения tid и key.
Лемма использует предикаты вида form F @ i, чтобы обозначить, что трассировка
содержит факт F в индексе i и предикаты формы i <j для обозначения, что
временная точка i меньше временной точки j. Лемма утверждает, что если поток tid
принял ключ в момент времени i и ключ также известен противнику, тогда должен
быть временной интервал l до i, где был раскрыт общий секрет.
Вывод. Запуск Tamarin этого входном файле дает следующий результат.
analyzed
example.spthy:
Accept_Secret
(all-traces)
verified (9 steps)
На выходе указано, что Tamarin успешно проверил, что все трассировки
удовлетворяют формуле Accept_Secret.
Тамарин написан на языке программирования Haskell. Его интерактивный
режим
реализован
как
веб-сервер,
обслуживающий
HTML-страницы
со
встроенным Javascript. На рисунке 2.5 показан интерактивный режим Тамарина,
который объединяет автоматизированный анализ и интерактивное доказательство,
предоставляющие подробную информацию о текущих ограничениях или
контрпримерных трассировках.
53
Рисунок 2.5 – Интерактивный режим инструмента Tamarin
SCYTHER TOOL – инструмент, для проверки, фальсификации и анализа
протоколов безопасности. Scyther является бесплатным и предоставляет ряд новых
функций, не предлагаемых другими инструментами, а также самую современную
производительность. Новые функции включают возможность неограниченной
проверки с
гарантированным
завершением,
анализ
бесконечного набора
трассировок с точки зрения шаблонов и поддержку многопротокольного анализа.
Scyther основан на алгоритме уточнения шаблона, обеспечивая краткие
представления (бесконечных) наборов трассировок.
Инструмент
предоставляет
графический
интерфейс
пользователя,
представленный на рисунке 2.6, который дополняет интерфейсы командной строки
и интерфейса Python. Графический интерфейс предназначен для пользователей,
заинтересованных в проверке или понимании протокола. Интерфейсы командной
строки и скриптов облегчают использование Scyther для широкомасштабных
проверок протоколов.
54
Рисунок 2.6 – Графический интерфейс пользователя
Scyther сочетает в себе ряд новых функций и усовершенствованную
производительность. Во-первых, Scyther гарантированно завершается, позволяя
доказать правильность протоколов для неограниченного количества сеансов и
может произвольно выводить дерево доказательств (используя «back-end»). В
отличие от других неограниченных инструментов проверки, инструмент дает
полезные результаты даже в том случае, если не обнаружена атака, но также не
может быть установлена корректность. В таких случаях результаты Scyther имеют
аналогичную интерпретацию как ограниченные инструменты проверки, заявляя,
что никакой атаки не существует в пределах определенной границы.
Во-вторых, Scyther помогает в анализе протоколов, предоставляя классы
поведения протокола (или классы атак), в отличие от только трассировочной
информации одиночной атаки, которую выводят другие инструменты анализа. Втретьих, Scyter облегчает так называемый многопротокольный анализ. При таком
55
анализе анализируется параллельный состав двух протоколов. Традиционно такой
анализ
был
недопустим
для
инструментов
протокола.
Благодаря
производительности, предоставляемой инструментом Scyther, многопротокольный
анализ стал практически осуществимым и может быть выполнен просто проверкой
конкатенации файлов описания нескольких протоколов. Учитывая описание
протокола на языке spdl, основанного на оперативной семантике, инструмент
можно использовать тремя способами: для проверки наличия или отсутствия
утверждений безопасности в описании протокола; автоматически генерировать
соответствующие требования безопасности для протокола и проверять их;
анализировать протокол, выполняя полную характеристику. Ниже описывается
каждый из этих режимов.
Проверка требований. Язык ввода Scyther позволяет специфицировать
свойства безопасности, то есть в спецификации роли можно утверждать, что
определенное
значение
определенные
свойства
является
должны
конфиденциальным
выполняться
для
(секретность)
партнеров
по
или
связям
(аутентификация). Scyther может использоваться проверку этих свойств и
фальсификацировать их.
Автоматические требования. Если спецификация протокола не содержит
требований безопасности, Scyther может автоматически генерировать требования.
В конце каждой роли добавляются утверждения аутентификации, утверждая, что
предполагаемые партнеры по связи должны были выполнить протокол, как
ожидалось. Аналогично, требования секретности добавляются для всех локально
порожденных значений (nonces) и переменных. Это расширенное описание
протокола затем анализируется Scyther, как в предыдущем случае. Это позволяет
пользователям быстро оценивать свойства протокола.
Характеристика. Для анализа протокола каждая роль протокола может быть
«охарактеризована», а это означает, что Scyther анализирует протокол и
предоставляет конечное представление всех трассировок, которые содержат
выполнение роли протокола. В большинстве случаев это представление состоит из
небольшого числа (1-5) возможных шаблонов исполнения. Ручным контролем этих
56
шаблонов можно быстро получить представление о потенциальных проблемах с
протоколом и при необходимости изменить его. Например, учитывая протокол
Needham-Schroeder, Scyther определяет, что для роли корреспондента существует
только два шаблона: одно - правильное поведение протокола, а другое - известная
атака «man-in-the-middle». Следовательно, нет других возможных способов
выполнения роли ответчика. Атака «man-in-the-middle» или же атака посредника –
вид атаки в криптографии, когда злоумышленник тайно ретранслирует и при
необходимости изменяет связь между двумя сторонами, которые считают, что они
непосредственно
общаются
друг
с
другом.
Является
методом компрометации канала связи, при котором взломщик, подключившись к
каналу между контрагентами, осуществляет вмешательство в протокол передачи,
удаляя или искажая информацию. Scyther может выполнять неограниченную
проверку большинства протоколов, так как каждый шаблон представляет собой
бесконечный набор трассировок.
Scyther принимает в качестве входных данных описание протокола
безопасности,
которое
включает
спецификацию
предполагаемых
свойств
безопасности, называемую требованиями безопасности, и оценивает их. Запустив
Scyther и выполнив, например, программу scyther-gui.py. Программа запустит два
окна: главное окно, в котором редактируются файлы, и окно «About», которое
показывает некоторую информацию об этом инструменте. В качестве примера
проверим протокол Needham-Schroeder и исследуем атаку на него. Открыв
диалоговое окно и запустив файл ns3.spdl. Основное окно выглядит так, как
показано на рисунке 2.7. По соглашению, описание файла les имеет расширение
.spdl (язык описания протокола безопасности), но может иметь любое имя. Во
время процесса верификации появится новое окно. По завершении проверки окно
будет заменено на окно результатов, как показано на рисунке 2.8. Окно результатов
показывает сводку заявлений в протоколе и результаты проверки. Здесь можно
проверить правильность протокола. Самое главное, если требование протокола
неверно, тогда существует по крайней мере одна атака на протокол. Рядом с
57
заявлением отображается кнопка: нажав эту кнопку, есть возможность просмотреть
атаки на протокол, как показано на рисунке 2.9.
Входной файл, который принимает инструмент Scyther свободно основан на
синтаксисе C / Java. Основная цель языка - описать протоколы, определяемые
набором ролей. Роли, в свою очередь, определяются последовательностью
событий, большинство из которых являются событиями, которые обозначают
отправку или получение условий.
Рисунок 2.7 – Главное окно инструмента Scyther c открытым файлом ns3.spdl
58
Рисунок 2.8 – Окно результатов инструмента Scyther
Рисунок 2.9 – Окно атаки инструмента Scyther
59
Alloy (analyzer) – формальный язык моделирования с простым синтаксисом,
основанный на обозначениях в объектно-ориентированном сегменте и семантике,
которая
базируется
на
отношениях.
Основным
преимуществом
данной
формального языка является средство для анализа (Alloy analyzer), которое
позволяет анализировать спецификации языка. Процесс анализа основан на
переводе спецификаций Alloy (где домены ограничены конечными размерами) в
пропозициональную формулу, которая затем анализируется с использованием
готовых задач выполнимости булевых формул (SAT решений). Ограничение
размеров доменов напрямую влияет на выводы, которые мы можем получить в
процессе анализа. Если контрпример для данного утверждения найден, то модель
скорее всего ошибочна. С другой стороны, если контрпример не найден, можно
сделать вывод о том, что не существует никаких контрпримеров, когда размеры
домена ограничены данными границами. Выбор больших границ может
свидетельствовать о существовании
ранее непредвиденных ошибок. Эти
ограничения, которые предлагает инструмент Alloy analyzer необходимы для
анализа моделей и устранения большинства ошибок, возникающих в процессе
моделирования. В то же время модели приложений могут также выиграть от
использования инструмента Alloy analyzer, но на это нельзя полностью
положиться.
Облегченные формальные методы с ограничениями Alloy analyzer не могут
полностью полагается на данный инструмент при работе с критическими
моделями. Альтернативой является использование тяжеловесных формальных
методов, таких как, например, полуавтоматические инструменты проверки. У
полуавтоматически инструментов проверки тоже есть ограничения. Во-первых,
они требуют от пользователя опыта, который во многом препятствует их
использованию.
Кроме
того,
полуавтоматические
или
автоматические
инструменты используют свои собственные языки, которые являются сложными
языками для понимания и как следствия для моделирования. Это снижает удобство
использования непродвинутыми пользователями, а также является источником
ошибок в случае, если необходимо перевести облегченные модели. Не менее
60
важно, что незначительные ошибки в модели могут потребовать повторных
доказательств, которые использовали неправильные гипотезы. Во многом ошибки,
упущенные при выявлении требований к программному обеспечению, оказывают
большее влияние на более продвинутый этап разработки. Следовательно,
избавление от как можно большего числа ошибок в модели до начала процесса
доказательства теоремы является обязательным.
На рисунке 2.10 представлен рисунок главного окна инструмента Alloy
analyzer.
Рисунок 2.10 – Главное окно инструмента Alloy analyzer с алгоритмом для
моделирования
Пользовательский интерфейс состоит из панели редактирования и панели
сообщений. Относительные размеры панелей можно отрегулировать, щелкнув и
перетащив разделительные полосы, которые отделяют панели. Панель редактора:
содержит текстовый редактор с вкладками для изменения моделей. Он
поддерживает табуляцию, поэтому предусмотрела возможность редактирования
нескольких текстовых файлов одновременно. Также поддерживается подсветку
ошибок во время компиляции модели. Панель сообщений: отображает результаты
анализа. Каждый контрпример и каждый удовлетворяющий экземпляр будут иметь
интерактивную гиперссылку. Нажав на которую, запустится инструмент, для
61
отображения контрпримера или экземпляра. Например, если модель не может быть
скомпилирована, отображается сообщение об ошибке, и ошибка будет подсвечена
в исходной модели, как это представлено на рисунке 2.11.
Рисунок 2.11 – Сообщение о несоблюдении синтаксиса
Рисунок 2.12 – Параметры настройки инструмента Alloy analyzer
Список настроек, которые можно установить во вкладке параметров,
представленные на рисунке 2.12:
62
1.
SAT решение: Alloy 4 поставляется с SAT решениями. По умолчанию
выбран Java «SAT4J» поскольку он работает на каждой платформе и операционной
системе. Если требуется более высокая производительность, можно попробовать
один из родных средств, таких как MiniSat или ZChaff. Но если MiniSat или ZChaff
выходят из строя из-за несовместимости платформы или операционной системы,
то необходимо сменить на SAT4J.
2.
Предупреждения являются фатальными: по умолчанию модель,
содержащая одно или несколько предупреждений компиляции, не может быть
выполнена.
3.
Максимальная память для использования: объем памяти, выделяемый
для Alloy 4; более крупные и более сложные модели требуют больше памяти.
4.
Подробность сообщений: определяет, насколько подробными будут
сообщения.
5.
Размер шрифта: этот параметр определяет размер шрифта на панели
редактора и панели сообщений.
6.
Шрифт: данная настройка управляет шрифтом на панели редактора и
панели сообщений.
7.
Размер вкладки: определяет размер вкладки в панели редактора.
8.
Глубина Сколема: этот параметр контролирует максимальную глубину
чередующегося квантора. Если формула превышает эту глубину, функция Сколема
для нее генерировать не будет.
9.
Стратегия минимизации ядра Unsat: данный параметр контролирует
стратегию, используемую для минимизации ненадежного ядра. Быстрая стратегия
вообще сводится к минимуму. Среднесрочная стратегия использует гибридный
алгоритм, который пытается уменьшить размер ядра. Медленная стратегия
гарантирует, что на логическом уровне ядро является локально минимальным.
10. Автоматическая визуализация: если этот параметр включен, после
выполнения любой команды Alloy analyzer автоматически загрузит визуализатор,
чтобы визуализировать контрпример или экземпляр (если есть).
63
11. Запись входных и выходные данных Kodkod: если этот параметр
включен, после выполнения любой команды, Alloy Analyzer будет записывать
входную модель Kodkod, сгенерированную для этой команды, а также решение
Kodkod, соответствующее этой команде.
Kodkod – эффективное средство для решения ограничений SAT логики
первого порядка, которое содержит отношения, транзитивные замыкания,
арифметику
бит-векторов
и
частичные
моделями.
Он
предоставляет
автоматические средства для обоснования как удовлетворительных, так и
неудовлетворительных проблем: конечный поиск модели для первого и
минимальный недопустимый основной экстрактор для последнего. Kodkod
используется в широком спектре приложений, включая проверку кода, генерацию
тестового случая, декларативное выполнение, декларативную конфигурацию.
Результаты анализа протоколов представлены в приложении А, где
рассматриваются следующие протоколы: протокол аутентификации bull (BAP), eAuction, протокол аутентификации Gong (Gong), Salary Sum, TMN, Wired
Equivalent Privacy Protocol (WEP), NSPK, 3-Pass, протокол Диффи-Хеллмана (DH),
IKA, SSH, IKE. Эксперименты проводились на процессоре Intel (R) Core i5-4310U
2,00 ГГц с 16 ГБ оперативной памяти. Использование памяти для каждого процесса
было не ограничено. Потребление памяти определялось с использованием команды
GNU time9, вычисляющей реальное время и максимальный размер страниц памяти
для каждого запуска инструмента. Все тестовые файлы выполнялись с тайм-аутом
в течение 24 часов с помощью команды GNU timeout10. По соображениям точности
анализ протокола повторялся 50 раз, если для анализа требовалось менее 1 часа.
Затем вычислялось среднее значение времени и использования памяти. Когда
требуется более 1 часа, повторения ограничились 10 итерациям.
За последнее время было разработано несколько автоматических средств
проверки криптографических протоколов. Они действительно полезны, чтобы
помочь сделать безопасные протоколы. Лишь немногие из этих инструментов
способны анализировать алгебраические свойства. В таблицах сравнивалось время
64
выполнения и потребление памяти основных бесплатных инструментов. Был
проанализирован 21 протокол.
В приложении А таблицы A.1 приведены результаты анализа протоколов, в
основе которых содержится свойство исключающего «ИЛИ». В приложении А
таблицы A.2 приведены результаты анализа протоколов, основанных на свойствах
Диффи-Хеллмана. В приложении А таблицы A.3 приведены результаты анализа
протоколов со свойствами аутентификации.
Важно отметить, что все инструменты не имеют одинаковых целей.
Например, CL-Atse и OFMC предназначены для поиска атак и остановки после их
обнаружения.
TA4SP,
Tamarin
и
Scyther
являются
инструментами
для
доказательства и пытаются найти атаки на каждое свойство, даже если они уже
обнаружили одно из них.
Каждый инструмент имеет собственную стратегию, основанную на его
теоретических основах, чтобы найти атаку или доказать свойства безопасности.
Как видно из результатов анализа протоколов, ни одно инструментальное средство
не показало наивысших результатов по сравнению с другими. У каждого
инструмента имеются свои сильные и слабые стороны. В связи с этим было
принято решение выбрать инструмент ProVerif для анализа открытых протоколов
OAuth и OpenID Connect, так как его показатели являются наиболее
предпочтительными.
2.2 Анализ открытого протокола OAuth
OAuth по существу состоит из четырех объектов: владельца ресурса,
клиента, сервера авторизации, сервера ресурсов. Информация передается
посредством общедоступных (например, Интернет) и частных (через TLS) каналов.
В формализации описано четыре параллельных процесса: User Agent (который
моделирует веб-браузер и владельца ресурса вместе), Client (Клиент), Resource
Server(сервер ресурсов) и Authorization Server (сервер авторизации, который, в
свою очередь, разделен на получение кода авторизации, токена доступа и токена
обновления). Создано два канала: free net: channel для представления общего канала
65
и free TLS_pass: channel [private] частный TLS канал. Чтобы эффективно
представить эти частные каналы и их создание во время выполнения процесса, был
использован частный канал передачи TLS и некоторые константы: (c1, c2, c3, c4).
Создание и установление клиентского TLS-соединения:
new TLSchannel2: channel;
out(TLS_pass, TLSchannel2);
out(TLSchannel2,(grant_type,X_client_id,X_client_pass
word, code, redirect_uri, c2));
in(TLS_pass, TLSchannel2:channel);
in(TLSchannel2,(=grant_type,client_id:bitstring,
client_password:bitstring,auth_code:bitstring,client_redire
ct_uri:bitstring,=c2));
Сначала клиент создает новое соединение TLSchannel2 и передает его
каналу TLS_pass. Это устанавливает соединение и имитирует обмен информацией
и ключами протокола TLS. В строках out(TLSchannel2,
(grant_type,
X_client_id, X_client_password, code, redirect_uri, c2)) и
in(TLSchannel2,
(=grant_type,
client_password:bitstring,
client_id:bitstring,
auth_code:bitstring,
client_redirect_uri:bitstring, =c2)) происходит фактический обмен
сообщениями через установленное TLS соединение с постоянным контролем.
table RegisteredClients(bitstring, bitstring)
table AuthCodes(bitstring, bitstring, bitstring)
table RefreshTokens(bitstring, RefreshToken)
table mac_keys(Token, bitstring)
Чтобы имитировать базы данных сервера авторизации, необходимо создать
четыре таблицы ProVerif, которые будут позволять вводить и получать данные
через специальные функции, называемые insert и get. Таблица RegisteredClients
была создана для имитации зарегистрированных клиентов, у которых есть
разрешения на аутентификацию на сервере, таблица AuthCodes, где хранятся коды
авторизации и URI-перенаправления, назначенные каждому клиенту, таблица
66
RefreshToken предназначена для проверки принадлежности конкретного токена
обновления клиенту.
События:
event auth_request(bitstring)
event auth_accepted(bitstring, bitstring)
event token_request(bitstring, bitstring)
eventtoken_grant(bitstring,bitstring,Token,RefreshTok
en)
event resource_request(Token, mac)
event resource_accepted(Token, mac)
event token_refresh(bitstring, RefreshToken)
Чтобы иметь возможность контролировать все отдельные события и
устанавливать требования безопасности необходимо создать несколько событий,
которые представляли бы события протокола.
Код авторизации:
query
client_id:bitstring,
authcode:bitstring;
inj-
event(auth_accepted(client_id,authcode))==>injevent(auth_re
quest(client_id))
Для каждого клиента должен формироваться и отправляться один и только
один код авторизации.
Токен доступа:
Query
client_id:bitstring,authcode:bitstring,tokencode:Token,refr
eshcode:RefreshToken;event(token_grant(client_id,authcode,t
okencode,refreshcode))==>(event(token_request(client_id,aut
hcode))||event(token_refreshed(client_id,refreshcode)))
query
client_id:bitstring,refreshcode:RefreshToken;event(token_re
67
freshed(client_id,refreshcode))==>
event(token_refresh(client_id,refreshcode))
query
client_id:bitstring,authcode:bitstring,tokencode:Token,refr
eshcode:RefreshToken;event(token_grant(client_id,authcode,t
okencode,refreshcode))==>event(auth_accepted(client_id,
authcode))
query
client_id:bitstring,tokencode:Token,refreshcode:RefreshToke
n,authcode:bitstring;event(token_refreshed(client_id,refres
hcode))==>event(token_grant(client_id,authcode,tokencode,re
freshcode))
Для каждого отправленного токена должен быть запрос на наличие и
формирование нового токена или запрос на обновление существующего /
истекшего, с тем же кодом авторизации / обновления для данного клиента.
Также требуется чтобы для каждого отправленного токена было допущено
событие. И необходим запрос, который отправлял бы конкретному клиенту токен
обновления.
Ресурс:
query
tokencode:Token,z:mac;event(resource_accepted(tokencode,z))
==> event(resource_request(tokencode,z))
query
client_id:bitstring,authcode:bitstring,tokencode:Token,refr
eshcode:RefreshToken,z:mac;event(resource_accepted(tokencod
e,z))==>(event(token_grant(client_id,authcode,tokencode,ref
reshcode))==>event(auth_accepted(client_id,authcode)))
Для каждого принятого и отправленного ресурса должен существовать
запрос на ресурс с тем же мак адресом и токеном. Также требуется запрос, чтобы
68
для каждого ресурса, принятого с заданным токеном, был отправлен токен и его
относительная авторизация.
Атаки злоумышленника:
query attacker(A_client_password);
(* attacker(secretTokenC); *)
attacker(secretMACKeyC);
attacker(secretTokenRefreshC);
attacker(secretMACKey2C);
(* attacker(secretTokenRefreshedC); *)
(* attacker(secretTokenAS); *)
attacker(secretTokenRefreshAS1);
(* attacker(secretTokenRefreshedAS); *)
attacker(secretTokenRefreshAS2);
attacker(secretMACKeyAS);
attacker(secretMACKey2AS);
(* attacker(secretTokenRS); *)
attacker(secretMACKeyRS).
not attacker(TLS_pass).
С помощью злоумышленников, наконец, можно перейти к запросам,
касающимся конфиденциальности. В процессах модели Proverif необходимо очень
часто создавать токены, коды авторизации и ключи. И эти переменные были
созданы с помощью новой конструкции. Proverif может проверять только
секретность свободных переменных, созданных в начале модели. Чтобы обойти это
ограничение, для каждой переменной, созданной с помощью новой конструкции,
была создана глобальная и свободная переменная.
Чтобы иметь большую точность в результате тестирования протокола, было
создано больше свободных переменных, которые располагаются в разных
процессах. Таким образом, для проверки секретности токена обновления, была
создана переменная secretTokenRefreshC (используется в процессе клиента) и
свободная переменная secrettokenRefreshAS1 (используется в процессе AS).
69
Прежде всего, главное требование это, чтобы пароль клиента не был
обнаружен третьими лицами. Впоследствии, используя описанные выше
переменные, требуется секретность ключа MAC и токена обновления во всех
местах, где они используются.
В последней атаке устанавливается значение not attacker(TLS_pass), так как
канал TLS не может быть атакован, поскольку формализация заключается в
установлении TLS-соединения, и Proverif необходимо сообщить о том, что TLS
канал считается безопасным.
Веб-браузер:
event auth_request(client_id);
out(TLSchannel1,(response_type,client_id,client_redir
ect_uri, c1));
in(net, code:bitstring);
out(net, code);
Сервер авторизации:
in(TLSchannel1,(=response_type, client_id:bitstring,
client_redirect_uri:bitstring, =c1));
get RegisteredClients(=client_id, client_password) in
new auth_code:bitstring;
event auth_accepted(client_id, auth_code);
out(net, auth_code);
insert
AuthCodes(auth_code,client_id,client_redirect_uri);
На стороне веб-браузера через TLS канал оправляется запрос, в котором
находится указания типа доступа, идентификатор клиента, URI перенаправления и
константу для определения конкретного запроса. На запрос в строку «in» через
канал «net» приходит код авторизации, получив код авторизации клиент
отправляет его серверу для дальнейшего получения токена доступа.
На стороне сервера в строку «in» через канал TLSchannel1 поступает тип
доступа, отправленный клиентом, идентификатор клиента, URI перенаправления и
70
константа. После этого сервер авторизации проверяет авторизацию клиента, а
также получает пароль клиента через запрос get RegisteredClients, после этого
создается новая строка с кодом авторизации, с помощью new auth_code:bitstring,
отправляется клиенту и заносится в таблицу с кодами, где хранится код
авторизации, идентификатор клиента и URI перенаправления.
Получив код авторизации, можно выполнить запрос токена доступа
клиентом.
Клиент:
event token_request(A_client_id, code);
out(TLSchannel2,(grant_type,X_client_id,X_client_pass
word,code,redirect_uri, c2));
in(TLSchannel2,(token_code:Token,=token_type,mac_key:
bitstring,=mac_algorithm,refresh_token:RefreshToken, =c3));
Сервер авторизации:
in(TLSchannel2,(=grant_type,client_id:bitstring,
client_password:bitstring,auth_code:bitstring,client_redire
ct_uri:bitstring, =c2));
get RegisteredClients(=client_id,=client_password)in
get
AuthCodes(=auth_code,=client_id,=client_redirect_uri)in
new token_code:Token;
new refreshToken_code:RefreshToken;
new mac_key: bitstring;
event
token_grant(client_id,
auth_code,
token_code,
refreshToken_code);
out(TLSchannel2,(token_code,token_type,mac_key,mac_al
gorithm, refreshToken_code,c3));
insert mac_keys(token_code, mac_key);
insert RefreshTokens(client_id,refreshToken_code);
71
(*out(net,senc(secretTokenAS,Token_to_bitstring(token
_code))); *)
out(net,
senc(secretTokenRefreshAS1,RefreshToken_to_bitstring(refres
hToken_code)));
out(net, senc(secretMACKeyAS, mac_key));
На стороне клиента, через канал TLSchannel2 клиент отправляет серверу
авторизации метод авторизации, идентификатор клиента, пароль клиента, код
авторизации, URI перенаправления и константу для проверки точности запроса. И
ждет получения на канал TLSchannel2, токена доступа, тип токена, мак ключ, мак
алгоритм, токен обновления и идентичную константу, которую отправил чуть
ранее.
На стороне сервера авторизации, на канал TLSchannel2 поступает
информация о метод авторизации, идентификаторе клиента, пароле клиента, коде
авторизации, URI перенаправления и константа для проверки точности запроса.
После получения этой информации сервер авторизации проверяет авторизацию
клиента. Затем, создается токен доступа, токен обновления, мак ключ, происходит
событие помещения в базу данных идентификатора клиента с его кодом
авторизации, токеном доступа и токеном обновления. После этого через канал
TLSchannel2 отправляется токена доступа, тип токена, мак ключ, мак алгоритм,
токен обновления и идентичная константу для проверки.
Клиент:
new N:nonce;
let(normalized_string:bitstring)=(N,resource_uri) in
let
mac_string=hmac_sha_256(normalized_string,
mac_key)in
event resource_request(token_code, mac_string);
out(net,(resource_uri,token_code,N,mac_string));
in(net, resource:bitstring);
out(net, F(resource));
72
Сервер авторизации:
in(net,(resource_url:bitstring,token_code:Token,
N:nonce, mac_string:mac));
let(normalized_string:bitstring)=(N,resource_url) in
get mac_keys(=token_code, mac_key) in
let
(=mac_string)=hmac_sha_256(normalized_string,
mac_key) in
event resource_accepted(token_code, mac_string);
out(net, resourcecontent(resource_url));
out(net,senc(secretTokenRS,Token_to_bitstring(token_c
ode)));
out(net, senc(secretMACKeyRS, mac_key));
На стороне клиента, когда токен доступа получен, у клиента есть
возможность обратиться к серверу авторизации за требуемым ресурсом.
Для этого генерирует константа с типом nonce, являющиеся уникальным
случайным набором букв и цифр, которая предназначена для уникальной
идентификации
каждого
подписанного
запроса.
После
этого
создается
нормализованная строка, в которую помещается константа с типом nonce и URI
ресурса. Затем строке mac_string присваивается хешированная с помощью
алгоритма hmac_sha_256, нормализированная строка и ключ мак. Происходит
событие resource_request, в котором указывается токен доступа и строка mac_string,
сгенерированная чуть выше. Через канал net серверу авторизации отправляется
URI ресурса, токен доступа, константа с типом nonce и строка mac_string. Затем
клиент ожидает от сервера авторизации ответа на запрос к ресурсу, на канал net
должен быть отправлен ресурс.
На стороне сервера авторизации, на канал net ожидается поступления URI
ресурса, токена доступа, константы с типом nonce и строки mac_string. После того
как эти данные получены, сервер авторизации проверяют нормализованную
строку, через функцию get mac_keys получает token_code для ключа мак и
73
проверяет верна ли строка mac_string. Если все данные совпадают, сервер
авторизации отправляет через канал net клиенту URI ресурса.
После создания модели протокол был запущен в инструменте ProVerif с
помощью
команды
./proverif oauth2-authorization-code.pv,
и
был
получен
следующий результат.
Рисунок 2.13 – Результат проверки открытого протокола OAuth, используя
закрытый канал
Обычно формальный ручной анализ протоколов является сложным и не
является безошибочным, использование Proverif позволило проверить протокол
простым и эффективным способом. Правильное использование OAuth в
соответствии с рекомендациями разработчиков, позволяет считать протокол
безопасным. Проблемы с протоколом могут возникнуть, если внешние операции,
связанные с протоколом, не защищены должным образом, такие как защита
учетных данных клиента, длительные сроки истечения токенов или неправильная
передача токенов, с помощью защищенного канала TLS.
Если не воспользоваться защищенным каналом TLS и использовать
общедоступный, то Proverif показывает, что злоумышленник может заполучить
данные пользователя.
74
Рисунок 2.14 – Результат проверки нескольких параметров открытого протокола
OAuth, используя открытый канал
Рисунок 2.15 – Подробный отчет проверки открытого протокола OAuth,
используя открытый канал
2.3 Анализ открытого протокола OpenID Connect
OpenID Connect был опубликован в феврале 2014 года, поскольку он
основан на открытом протоколе OAuth. У OpenID Connect имеется три стороны:
End_User (пользователь), Relay Part (доверенная сторона) и OpenID Provider
(провайдер OpenID). Пользователь является владельцем ресурса, данные которого
хранятся у провайдера OpenID. Доверенная сторона, является приложением,
75
предоставляющим определенную услугу, которая требует аутентификации,
делегирующая свои полномочия провайдеру OpenID. Провайдер OpenID способен
аутентифицировать пользователя и предоставить часть информации доверяющей
стороне об аутентификации и часть информации о пользователе. В OpenID Connect
существует три способа аутентификации: аутентификация с помощью кода
авторизации, неявный способ аутентификации и гибридный способ. При
проведении исследования был использован гибридный способ, поскольку он имеет
более наглядную структуру при реализации OpenID Connect.
Протокол OpenID Connect позволяет доверенной стороне проверять
идентификатор пользователя на основе аутентификации, выполняемой сервером
авторизации, который содержится у провайдера OpenID Connect, а также для
получения базовой информации профиля пользователя. Основной функцией
OpenID Connect является аутентификация, созданная поверх открытого протокола
OAuth, и передача информации о пользователе.
Аутентификация протокола OpenID Connect главным образом содержит
шесть обменов сообщениями между пользователем, провайдером OpenID и
доверенной стороной при использовании гибридного потока.
authenticationRe:=client_id||response_type||scope||re
direct_uri||state
Чтобы получить доступ к защищенным ресурсам пользователя, доверенная
сторона генерирует сообщение authenticationRe и отправляет его серверу
авторизации провайдеру OpenID для аутентификации. Параметры этого запроса в
основном содержат: client_id, который является идентификатором клиента,
действительным на сервере авторизации, значение response_type определяет способ
обработки авторизации, когда используется гибридный способ, это значение
является code_id_token_token, но в этой реализации это значение является code_
id_token, потому что здесь удаляется token, который является необязательным,
scope – это значение области OpenID, если оно не присутствует, поведение OpenID
полностью неопределено, redirect_uri точно соответствует одному из значений URI
перенаправления, предварительно запрограммированных клиентом у провайдера
76
OpenID, state – это значение, используемое для поддержания состояния между
запросом и обратным вызовом.
authenticationE_U:=ask_authentication
Когда сервер авторизации получил сообщение authenticationRe, он будет
проверять все параметры в соответствии со спецификацией OAuth и должен
проверить все присутствующие параметры и их использование. Затем сервер
авторизации
сгенерирует
сообщение
authenticationE_U,
которое
содержит
аутентификацию ask_authentication для аутентификации пользователя и отправляет
это сообщение пользователю.
authorization :=username||userpassword
Когда
пользователь
получил
сообщение
authenticationE_U
:=ask_authentication, он будет проверять параметр ask_authentication, если значение
параметра
true,
то
пользователь
создаст
сообщение
authorization
:=username||userpassword, в котором содержится имя пользователя и пароль. Затем
пользователь
отправляет
это
сообщение
провайдеру
OpenID
на
сервер
авторизации, который подтверждает, что пользователь авторизовался у провайдера
OpenID. Имя пользователя – это имя, которое ранее было зарегистрировано у
провайдера OpenID, а userpassword – секретный ключ пользователя, который был
заранее зарегистрирован у провайдера OpenID.
authenticationResp:=code||id_token
К
тому
времени,
когда
сервер
авторизации
получит
сообщение
authorization:=username||userpassword, в котором содержится информация об имени
и пароле пользователя, отправленные пользователем, серверу авторизации
необходимо
сгенерировать
сообщение
authenticationResp
:=code||id_token,
содержащее в себе code и id_token и которое необходимо отправить доверенной
стороне. Сode – это код авторизации, который используется для обмена на токен
доступа.
Tokenrequest:=grant_type||code||redirect_uri||client_
secret||client_id
77
Когда
доверенная
сторона
получила
сообщение
authenticationResp
:=code||id_token, оно будет являться действительным, если код будет правильным и
не был использован до этого. Затем доверенная сторона генерирует сообщение
tokenrequest, которое содержит параметр grant_type, это значение указывает, что
доверенная сторона хочет использовать код для получения токена доступа из
конечной точки провайдера OpenID, code, который соответствует коду сообщения
authenticationResp сопоставляется с сообщением authenticationRe, client_secret – это
секретный ключ, который совместно используется доверенной стороной и
провайдером OpenID, client_id является тем же самым client_id в сообщении
authenticationRe. Наконец, доверенная сторона отправляет сообщение tokenrequest
провайдеру OpenID.
token_response:=access_token||id_token||token_type||e
xpiress_in||signedMessage
После того, как провайдер OpenID получил сообщение Tokenrequest, вопервых, он должен проверить значения grant_type и code, если эти значения
проверены, провайдер OpenID генерирует сообщение token_response, которое
содержит токен доступа, который является доказательством того, что пользователь
прошел аутентификацию, id_token то же самое что и в
сообщении
authenticationResp, token_type, значением которого является Bear, expiress_in
является временем жизни токена доступа, signedMessage - это цифровая подпись,
которая использует закрытый ключ провайдера OpenID. Наконец, провайдер
OpenID
отправляет
сообщение
token_response
доверенному
лицу.
Когда
доверенное лицо получает сообщение token_response, во-первых, он проверяет
цифровую подпись открытым ключом провайдера OpenID, если проверка прошла
успешно, протокол завершен. Процедура детализации показана на рисунке 2.16.
78
Рисунок 2.16 – Процедура получения токена открытого протокола OpenID
Connect
2.3.1 Формализация протокола OpenID Connect с использованием
прикладного Пи-исчисления
Прикладное Пи-исчисление было разработано Абади в 2001 году. Пиисчисление – это формальный язык, который использовался для моделирования
соответствия между параллельными процессами. Прикладные исчисления
добавили функции и примитивы уравнений на основе структуры соответствия и
совпадения. Сообщение может содержать не только имена, но и значения,
состоящие из имен и функций. С помощью Пи-исчисления удобно описывать тип
79
стандартных данных, также формальное моделирование протоколов безопасности.
Пи-исчисление обозначает значения переменных с любым типом, значения атома
с
именами
и
криптографические
примитивы,
такие
как
шифрование,
дешифрование, подпись и исключающее «ИЛИ» с функциями, поэтому Пиисчисление можно использовать для моделирования и анализа сложных
протоколов безопасности.
Чуть ниже будут описаны функции и эквациональная теория открытого
протокола OpenID Connect с использованием прикладного Пи-исчисления.
Функция fun sign(x,PR) используется для того, чтобы подписать сообщение x
(шифрует) с помощью частного ключа PR, функция versign(x,PU) используется для
того, чтобы проверить цифровую подпись x с помощью открытого ключа PU,
функция decsign(x,PU) восстанавливает (дешифрует) сообщение из цифровой
подписи x с открытым ключом PU. Функция fun PR (b) принимает частное значение
b как входное значение и выдает закрытый ключ в качестве выводного значения.
Функция fun PU (b) принимает значение открытого ключа b как входное значение
и выдает открытый ключ в качестве выходного значения.
fun sign(x,PR).
fun PR(b).
fun PU(b).
fun versign(x,PU).
fun decsign(x,PU).
equation versign(sign(x,PR),PU)=x.
equation decsign(sign(x,PR),PU)=x.
Процесс OpenID Connect содержит в себе четыре процесса: основной
процесс, процесс пользователь, процесс провайдера OpenID и процесс доверенного
лица. Основной процесс OpenID состоит из процесса пользователь, процесса
провайдера OpenID и процесса доверенного лица.
OpenID=!processOP|!processRP|!processEU
Процесс пользователь сначала получает сообщение message2 через
свободный канал c от процесса провайдера OpenID с помощью инструкции
80
in(c,m2),
затем
процесс
пользователь
проверяет,
является
ли
параметр
ask_authentication равным сообщению message2 и затем генерирует имя
пользователя username, пароль пользователя userpassword и конструкцию secretX.
Наконец, процесс пользователь генерирует авторизацию сообщения, содержащую
имя пользователя и пароль пользователя, и отправляет его для обработки
провайдером OpenID через свободный канал c.
processEU= (*****Процесс пользователя********)
in(c,m2);
(*******пользователь
отправляет
сообщение
message2
провайдеру OpenID******)
if ask_authentication=m2 then
let secretX=userpassword in
let authorization = (username,userpassword) in
out(c,authorization).
(****пользователь отправляет сообщение
message3 провайдеру OpenID****)
Во-первых, процесс провайдер OpenID получает сообщение message1 из
процесса доверенного лица и извлекает параметры client_id_op, response_type_op,
scope_op,
redirect_uri_op,
state_op
из
сообщения
m1,
после
чего,
если
response_type_op равно значению code_id_token и scope_op равно значению code,
процесс провайдер OpenID будет создавать сообщение authenticationE_U, в
котором содержится ask_authentication и отправляет его процессу пользователь
через свободный канал c. Далее, он получает сообщение message3 от процесса
пользователь и извлекает username_op и userpassword_op из сообщения m3, если
username_op и userpassword_op совпадают с именем пользователя и паролем
пользователя, хранящимся у провайдера OpenID, то процесс провайдер OpenID
будет создавать параметры code_op и id_token_op и подписывать их с помощью
приватного ключа keyop2, а затем отправит сгенерированное сообщение
authorizationResp, в котором содержатся параметры code_op, id_token_op, signedM4
доверенному лиц через свободный канал c. Позже, процесс провайдер OpenID
получает сообщение message5 от доверенного лица, в котором содержатся
81
параметры grant_type, code_op, redirect_uri_op, client_secret_op и client_id_op и
проверит значения параметров grant_type и code_op, затем он создает параметры
access_token_op, id_token_op, token_type_op, expires_in_op и подписывает их с
использованием цифровой подписи с закрытым ключом keyop1, это генерирует
сообщение token_response, в котором содержатся параметры access_token_op,
id_token_op, token_type_op , expires_in_op и signedMessage и отправляет это
сообщение доверенному лицу через свободный канал c. После этого процесс
OpenID закончится.
processOP= (*****Процесс провайдера OpenID***********)
in (c,m1); (*****Провайдер OpenID отправляет сообщение message1
доверенному лицу******)
let(client_id_op,response_type_op,scope_op,redirect_u
ri_op,state_op)=m1 in
if scope_op=scope then
if response_type_op=code_id_token then
new ask_authentication;
let authenticationE_U=ask_authentication in
out(c,authenticationE_U); (*******Провайдер OpenID отправляет
сообщение message2 конечному пользователю*******)
in(c,m3); (********Провайдер OpenID получает сообщение message3 от
пользователь *******)
let (username_op,userpassword_op)=m3 in
if username_op=username then
if userpassword_op=userpassword then
new code_op;new id_token_op;
let signedM4=sign((code_op,id_token_op),PR(keyop2))in
let authorizationResp=(code_op,id_token_op,signedM4)in
out(c,authorizationResp); (*******Провайдер OpenID отправляет
сообщение message4 доверенному лицу********)
82
in(c,m5); (*******Провайдер OpenID получает сообщение message5 от
доверенного лиц ********)
let(grant_type_op,code_op,redirect_uri_op,client_secr
et_op,client_id_op)=m5 in
if grant_type_op=code then
if code_op=code then
new access_token_op;newid_token_op;
new token_type_op;new expires_in_op;
let
signedMessage=sign((access_token_op,id_token_op,token_type_
op,expires_in_op),PR(keyop1)) in
let
token_response=(access_token_op,id_token_op,token_type_op,e
xpires_in_op,signedMessage)in
out(c,token_response).
(**Провайдер
OpenID
отправляет
сообщение m6 которое подписано с помощью открытого ключа доверенного
лица**)
Процесс доверенного лица сначала генерирует сообщение authenticationRe,
которая содержит client_id, response_type, code, redirect_uri и state, и затем
отправляет это сообщение в процесс провайдера OpenID. Затем доверенное лицо
получает сообщение m4, отправленное провайдером OpenID через свободный
канал c, в котором содержится code_rp, id_token_rp и signedM4, после чего
доверенное лицо проверяет подписанное сообщение signedM4 используя открытый
ключ keyop2 провайдера OpenID. Затем доверенное лицо генерирует сообщение
tokenrequest, которое содержит параметры grant_type_rp, code_rp, redirect_uri_rp,
client_id и client_secret и отправляет это сообщение провайдеру OpenID через
свободный канал c. Наконец, процесс доверенного лица получает сообщение m6,
отправленное провайдером OpenID, в котором находится access_token_rp,
id_token_rp, token_type_rp , expiress_in_rp и signedMessage1. Доверенное лицо
проверяет подписанное сообщение signedMessage1 открытым ключом keyop1
83
провайдера OpenID, если проверка прошла успешно, создается параметр finished и
отправляет его через открытый канал, на этом процесс доверенного лица
заканчивается.
let processRP= (********Процесс доверенного лица ***********)
new
client_id;new
response_type;new
scope;new
redirect_uri;new state;
let
authenticationRe=(client_id,response_type,scope,redirect_ur
i,state) in
out(c,authenticationRe);
(**доверенное
лицо
отправляет
сообщение message1 провайдеру OpenID**)
in(c,m4); (******Доверенное лицо получает сообщение message4 от
провайдера OpenID******)
let (code_rp,id_token_rp,signedM4)=m4 in
if
versign((signedM4),PU(keyop2))=(code_rp,id_token_rp) then
new grant_type_rp;new code_rp;new redirect_uri_rp;
new client_secret_rp;new client_id_rp;
let
tokenrequest=(grant_type_rp,code_rp,redirect_uri_rp,client_
secret_rp,client_id_rp) in
out(c,tokenrequest); (**Доверенное лицо отправляет сообщение m5
провайдеру OpenID**)
in(c,m6);
let
(access_token_rp,id_token_rp,token_type_rp,expires_in_rp,si
gnedMessage1)=m6 in
if
versign(signedMessage1,PU(keyop1))=(access_token_rp,id_toke
n_rp,token_type_rp,expires_in_rp) then
84
new finished;
out(c,finished).( **Процесс закончен**)
2.3.2 Автоматическая проверка безопасности и аутентификации открытого
протокола OpenID Connect с помощью инструмента ProVerif
Использование запроса query attacker:secretX в ProVerif используется для
проверки секретности userpassword. ProVerif использует non-injective соглашение
для
моделирования
аутентификации,
описанное
ниже.
Таким
образом,
используется запрос query ev:e1 ==> ev:e2 для моделирования аутентификации. Это
верно, когда событие e1 выполнено, а затем событие e2 было выполнено до
события e1.
ev:endauthusera_s(x)==>ev:beginaauthusera_s(x) – сервер
авторизации аутентифицирует пользователь.
–
ev:endautha_suser(x)==>ev:beginaautha_suser(x)
пользователь аутентифицирует сервер авторизации.
ev:endauthRPE_p(x)==>ev:beginaauthRpE_p(x)
–
токен
конечной точки аутентифицирует доверенное лицо.
ev:endauthE_pRP(x)==>ev:beginaauthE_pRP(x) – доверенное
лицо аутентифицирует токен конечной точки.
В инструменте ProVerif входные форматы состоят из хорновских
дизъюнктов и расширения прикладного Пи-исчисления, но они имеют одинаковую
систему вывода. Модель с использованием прикладного Пи-исчисления должна
транслироваться в синтаксис ProVerif, а входные значения в расширенные Пиисчисления. Ниже будут показаны входные значения для протокола OpenID
Connect.
query attacker:secretX.
query ev:endauthusera_s(x)==>ev:beginaauthusera_s(x).
query ev:endautha_suser(x)==>ev:beginaautha_suser(x).
query ev:endauthRPE_p(x)==>ev:beginaauthRpE_p(x).
query ev:endauthE_pRP(x)==>ev:beginaauthE_pRP(x).
85
if ask_authentication=m2 then
event endautha_suser(m2);
let secretX=userpassword in
let authorization = (username,userpassword) in
event beginaauthusera_s(authorization);
out(c,authorization).
event endauthE_pRP(signedM4);
let
tokenrequest=(grant_type_rp,code_rp,redirect_uri_rp,
client_secret_rp, client_id_rp) in
event beginaauthRpE_p(tokenrequest);
out(c,tokenrequest);
Результаты тестирования, показаны на рисунках 2.17-2.21. На рисунке 2.17
показан результат атакующего запроса query attacker:secretX. Из рисунка 2.17
видно, что secretX является небезопасным, потому что secretX был отправлен без
шифрования и через открытый канал, злоумышленнику легко рассекретить это
сообщение.
Рисунок 2.17 – Результат автоматического анализа инструментом Proverif
открытого протокола OpenID Connect
На рисунке 2.18 показан результат запроса query ev: endautha_suser (x) ==>
ev: beginaautha_suser (x), известно, что пользователь не может аутентифицировать
сервер авторизации, потому что сообщение, которое пользователь отправляет
86
является незашифрованным, и злоумышленнику может легко заполучить данные
этого сообщения.
Рисунок 2.18 – Результат автоматического анализа инструментом Proverif
открытого протокола OpenID Connect
На рисунке 2.19 показан результат запроса query ev: endauthusera_s (x) ==>
ev: beginaauthusera_s (x), где сервер авторизации не может аутентифицировать
пользователь, поскольку протокол не использует безопасный подход, когда
пользователь отправляет имя пользователя и пароль серверу авторизации.
Рисунок 2.19 – Результат автоматического анализа инструментом Proverif
открытого протокола OpenID Connect
На рисунке 2.20 показан результат запроса query ev: endauthRPE_p (x) ==>
ev: beginaauthRpE_p (x), где видно, что результат является ложным, поскольку
конечная точка токена не может аутентифицировать доверенное лицо, потому что
доверенное лицо не использует никаких подходов безопасности, когда отправляет
сообщение tokenrequest провайдеру OpenID.
87
Рисунок 2.20 – Результат автоматического анализа инструментом Proverif
открытого протокола OpenID Connect
На рисунке 2.21 показан результат запроса query ev: endauthE_pRP (x) ==>
ev: beginaauthE_pRP (x), результат верен, и это указывает на то, что доверенное
лицо может аутентифицировать конечную точку токена, поскольку использует
цифровую подпись, которая является способом обеспечения безопасности, когда
сервер отправляет сообщение authorizationResp доверенному лицу.
Рисунок 2.21 – Результат автоматического анализа инструментом Proverif
открытого протокола OpenID Connect
88
3 МЕТОДЫ ЗАЩИТЫ ОТКРЫТЫХ ПРОТОКОЛОВ OAUTH И OPENID
CONNECT ОТ МЕЖСАЙТОВОЙ ПОДДЕЛКИ ЗАПРОСОВ И ФИШИНГА
3.1 Межсайтовая подделка запроса в открытых протоколах OAuth и OpenID
Connect
Свойства безопасности OAuth были проанализированы с использованием
формальных методов. Pai et al. [17] подтвердил проблему безопасности, описанную
в статье OAuth Thread Model [15], используя Alloy Framework [12]. Chari et al.
проанализировал OAuth в Universal Composability Security Framework [5] и показал,
что OAuth является безопасным, если все линии связи защищены с помощью SSL.
Frostig и Slack [21] обнаружили межсайтовую подделку запроса в «неявном»
методе OAuth, используя Murphi framework [8]. Bansal et al. [1] проанализировал
безопасность OAuth с использованием моделей WebSpi [2] и ProVerif [4]. Тем не
менее, вся эта работа основана на абстрактных моделях, и поэтому тонкие детали
реализации игнорируются. Ряд авторов также рассмотрели свойства безопасности
реализаций реального мира OAuth. Wang et al. [23] рассмотрел развернутую
систему
единого
входа,
сосредоточившись
на
логическом
недостатке,
присутствующем во многих таких системах, включая OpenID. Параллельно Sun и
Beznosov [22] также изучали развернутые системы OAuth. Позже Li и Mitchell [13]
рассмотрели безопасность развернутых систем OAuth, предоставляющих услуги на
китайском языке. Параллельно, Zhou и Evans [25] провели широкомасштабное
исследование безопасности реализации OAuth Facebook. Chen et al. [6], Shehab и
Mohsen [19] рассмотрели безопасность версий OAuth на мобильных платформах.
Li и Mitchel [14] провели эмпирическое исследование безопасности службы
единого входа OpenID Connect, предоставляемой Google. Эти последние
исследования выявили ряд уязвимостей, возникающих при реализации этих
систем. Особый интерес представляют уязвимости, которые могут привести к
атакам CSRF, и ниже будет рассказано как эти атаки могут возникнуть и как
защитить открытые протоколы OAuth и OpenID Connect от межсайтовой подделки
запроса.
89
3.1.1 Описание и виды межсайтовой подделки запроса
Предполагается, что у противника есть возможности веб-злоумышленника,
то есть он может обмениваться вредоносными ссылками или отправлять
комментарии, содержащие вредоносный контент (например, таблицы стилей или
изображения) на веб-сайт, и/или использовать уязвимости на веб-сайте
клиентского приложения. Вредоносный контент может заставить веб-браузер
отправлять HTTP / HTTPS-запросы клиентскому приложению и провайдеру
идентификации, используя методы GET или POST, выполнять скрипты, созданные
злоумышленником.
Атака межсайтовой подделки запроса (CSRF) работает в режиме
постоянного взаимодействия между веб-браузером (от имени пользователя) и вебсайтом. Атака заключается в том, что вредоносный веб-сайт, заставляет веббраузер
инициировать
запрос
злоумышленника
на
целевой
сайт.
Это может привести к тому, что целевой сайт выполнит действия без участия
пользователя. В частности, если пользователь в настоящее время зарегистрирован
на целевом веб-сайте, целевой веб-браузер отправит на целевой веб-сайт куки,
содержащие токен аутентификации, сгенерированный целевым веб-сайтом для
целевого пользователя, вместе с запросом, предоставляемым злоумышленником.
Затем целевой сайт обработает вредоносный запрос, поскольку он был
инициирован целевым пользователем.
Существуют различные способы, с помощью которых целевой браузер
может быть сделан для отправки ложного запроса. Например, вредоносный вебсайт, посещенный браузером, может использовать атрибут src тега HTML <img>,
чтобы указать URL-адрес вредоносного запроса, который заставит браузер молча
использовать метод GET для отправки запроса на целевой сайт.
Согласно отчету 2013 года, OWASP Top 10 [16], выпущенному проектом
Open Web Application Security Project (OWASP), межсайтовая подделка запроса
оценивается 8 из 10, как наиболее важная угроза безопасности веб-приложений.
Это означает, что такие атаки представляют реальную опасность.
90
Межсайтовая подделка запроса в OAuth может позволить злоумышленнику
получить разрешение на доступ к защищенным ресурсам OAuth без согласия
пользователя. Такая подделка запроса возможна как для метода «код авторизации»,
так и для «неявного» метода.
Злоумышленник сначала получает код или токен доступа, относящиеся к
его собственным защищенным ресурсам. Затем прерывает перенаправление
обратно в клиентское приложение на собственном устройстве, а затем, обманывает
жертву и выполняет перенаправление обратно на клиентское приложение.
Клиентское приложение получает перенаправление, извлекает атрибуты от
провайдера
идентификации,
и
связывает
сессию
жертвы
с
ресурсами
злоумышленника, доступными с помощью токенов. Затем пользователь-жертва
обращается к ресурсам от имени злоумышленника.
Воздействие такой атаки зависит от типа доступа к ресурсам. Например,
пользователь может загружать личные данные в клиентское приложение, считая,
что он загружает информацию в свой собственный профиль, но эти данные
впоследствии будут доступны для злоумышленника. Как описано в работе Li и
Mitchell [13], злоумышленник может использовать межсайтовую подделку запроса
для управления учетной записью клиентского приложения, не зная имени
пользователя и пароля.
Barth et al. [3] описывает четыре механизма, которые веб-сайт может
использовать против межсайтовой подделки запроса: проверка секретного токена,
проверка заголовка HTTP Referer, включая дополнительные заголовки с
XMLHttpRequest и проверка заголовка HTTP Origin. Все эти механизмы сегодня
используются в Интернете, но ни один из них не является полностью
удовлетворительным:
1.
Секретный токен проверки. Один из способов защиты от межсайтовой
подделки запроса, где необходимо отправить дополнительную информацию в виде
секретного токена проверки в каждом HTTP-запросе. Этот токен может
использоваться для определения того, пришел ли запрос от авторизованного
источника. Токен проверки трудно угадать злоумышленнику, у которого еще нет
91
доступа к учетной записи пользователя. Если запрос не содержит токен проверки,
или токен не соответствует ожидаемому значению, сервер должен отклонить
запрос.
2.
Заголовок Referer. Во многих случаях, когда браузер выдает HTTP-
запрос, он включает заголовок Referer, который указывает, какой URL-адрес
инициировал запрос. Заголовок Referer, если присутствует, отличает запрос одного
сайта от запроса на межсайтовый сайт, потому что заголовок содержит URL-адрес
сайта, делающего запрос. Сайт может защищаться от атак с подделкой запросов на
межсайтовый запрос, проверяя, был ли данный запрос выпущен самим сайтом.
Однако Referer может содержать конфиденциальную информацию, которая
затрагивает безопасность пользователей.
3.
Собственные заголовки HTTP. Собственные HTTP-заголовки могут
использоваться для предотвращения межсайтовой подделки запроса, поскольку
браузеры не позволяют сайтам отправлять собственные HTTP-заголовки на другой
сайт, но позволяют сайтам отправлять собственные HTTP-заголовки сами себе с
помощью XMLHttpRequest.
Например,
библиотека
JavaScript prototype.js5
использует этот подход и присоединяет заголовок X-Requested-With со значением
XMLHttpRequest. Чтобы использовать собственные заголовки в качестве защиты,
сайт должен выдавать все запросы на изменение состояния с использованием
XMLHttpRequest, присоединять настраиваемый заголовок (например, X-Requestedwith) и отклонять все запросы на изменение состояния, которые не сопровождаются
данным заголовком. Это работает, потому что XMLHttpRequest не позволяет
злоумышленнику сделать запрос в домен третьей стороны по умолчанию. Таким
образом, злоумышленник не может подделать запрос с поддельным заголовком XRequested-With.
4.
Заголовок Origin. Во многих случаях браузер включает заголовок
Origin, который указывает, что запрос использует метод POST, также как и запрос
на перекрестный источник ресурсов (Cross-Origin Resource Sharing(CORS)). Его
использование похоже на заголовок Referer, но оно не содержит никакой
информации о пути, а только имя сервера.
92
Как описано в работе OAuth Threat model [15], есть два способа защититься
от межсайтовой подделки запроса, и они заключаются в следующем:

параметр state должен использоваться для связывания запроса
авторизации с URI-перенаправления, используемым для отправки кода или токена
доступа;

разработчики клиентского приложения и пользователи должны иметь
знания, чтобы не посещать ненадежные URL-адреса.
OAuth Threat model [15] не рекомендует использовать три других способа
защиты от межсайтовой подделки запроса, которые описаны выше. Это связано с
тем, что ответ OAuth при URI-переадресации является кросс-сайтовым запросом,
поскольку запрос генерируется провайдером идентификации и перенаправляется в
клиентское приложение браузером. Поэтому вся существующая защита от
межсайтовой подделки запроса (за исключением использования секретного токена)
не будет работать в этом случае.
Исследование, проведенное Shernan et al. [20] в 2015 году, обнаружило, что
25% веб-сайтов в домене Alexa Top 10 000, использующих OAuth для Facebook,
выглядят
уязвимыми
для
межсайтовой
подделки
запроса.
Кроме
того,
исследование 2016 года, проведенное Yang et al. [24] показало, что 61% из 405 вебсайтов, использующих OAuth (выбранные из 500 сайтов с высоким рейтингом
США и Китая), не применяли защиту от межсайтовой подделки запроса, что еще
хуже, для тех клиентских приложений, которые поддерживают параметр state, 55%
из них по-прежнему уязвимы для межсайтовой подделки запроса из-за
неправильного использования параметра state. Они также раскрыли четыре случая,
в которых параметр state может быть неправильно использован разработчиками
клиентского приложения. Это означает, что, если на практике предотвращать
межсайтовую подделку запроса, новые и простые в применении защиты будут
чрезвычайно ценными.
93
3.1.2 Защита метода «код авторизации» от межсайтовой подделки запроса
Поскольку требование добавления параметра state к запросу авторизации
часто игнорируется разработчиками, большое количество реализаций реального
мира OAuth уязвимы для межсайтовой подделки запроса. Кроме того,
традиционный заголовок Referer, заголовок Origin и собственные заголовки
недопустимы в рамках OAuth. Чтобы защититься от межсайтовой подделки
запросов необходимо объединить заголовок Referer и тот факт, что клиентские
приложения регистрируют разные URI-перенаправления для разных провайдеров
идентификации.
Обычно ответ авторизации генерируется
только после
того,
как
пользователь нажимает кнопку, предоставленную провайдером идентификации,
как это представлено на рисунке 3.1. HTTP-сообщение ответа авторизации
содержит
заголовок
Referer,
который
указывает
на
домен
провайдера
идентификации, который представлен ниже.
Пример 3.1 – Пример Google авторизации
Ответ авторизации OAuth, сгенерированный провайдером идентификации
для RP.com
GET /AIdP-callback?code=[af742jfs342kc8]
Host: RP.com
User-Agent: ***
94
Accept: ***
Accept-Language: en-US,en;q=0.5
Referer: https://AIdP.com/
Cookie: ***
Connection: close
На практике провайдеры идентификации, такие как Google, Facebook и
Microsoft, реализуют функцию автоматического разрешения полномочий [14]. То
есть, когда пользователь вошел в свою учетную запись OAuth, провайдер
идентификации генерирует ответ авторизации без явного согласия пользователя.
HTTP-сообщение, которое представлено ниже, такого ответа авторизации
содержит заголовок Referer, который указывает на домен клиентского приложения.
Предлагаемое решение действует следующим образом: когда клиентское
приложение получает ответ авторизации, сначала извлекается параметры
провайдера идентификации из URI-перенаправления, а затем происходит проверка,
что домен в заголовке Referer является либо доменом клиентского приложения,
либо доменом провайдера идентификации. Если домен заголовка Referer является
одним из этих двух значений, тогда клиентское приложение знает, что это
подлинный ответ авторизации, исходящий из провайдера идентификации, в
противном случае клиентское приложение должно отказаться от этого HTTPсообщения и отправить пользователю сообщение об ошибке.
Ответ
на
автоматическую
авторизацию
OAuth,
провайдером идентификации для RP.com.
GET /AIdP-callback?code=[af742jfs342kc8]
Host: RP.com
User-Agent: ***
Accept: ***
Accept-Language: en-US,en;q=0.5
Referer: https://RP.com/
Cookie: ***
Connection: close
сгенерированный
95
В качестве того, как это может работать на практике, предположим, что
злоумышленник помещает ссылку https://rp.com/AIdP-callback?code=[vdfgf32] на
атакующий сайт, чтобы попытаться запустить межсайтовую подделку запроса
против URI-перенаправления клиентского приложения, которое зарегистрировано
у провайдера идентификации. HTTP-сообщение межсайтовой подделки запроса
будет содержать заголовок Referer, который указывает на атакующий сайт, как
будет показано ниже. Клиентское приложение способно обнаружить это
сообщение, сравнивая идентификатор провайдера или собственный домен с
доменом в заголовке Referer.
GET /AIdP-callback?code=[vdfgf32]
Host: RP.com
User-Agent: ***
Accept: ***
Accept-Language: en-US,en;q=0.5
Referer: https://attacker.com/
Cookie: ***
Connection: close
3.1.3 Защита «неявного» метода от межсайтовой подделки запроса
Ниже будет описано, как заголовок Referer можно использовать для защиты
от межсайтовой подделки запроса в «неявном» методе открытого протокола OAuth
или «неявного» и «смешанного» методов для OpenID Connect.
В качестве примера того, как это может работать на практике, предположим,
что
злоумышленник
создает
ссылку
https://rp.com/AIdP-
callback#access_token=[490f94njsd51f] на сайте attacker.com, чтобы попытаться
запустить межсайтовую подделку запроса против клиентского приложения,
которое зарегистрировано у провайдера идентификации. Токен доступа в
«неявном»
методе
не
может
быть
сразу
передан,
когда
пользователь
перенаправляется на клиентское приложение. Таким образом, сообщение HTTPзапроса похоже на HTTP-запрос межсайтовой подделки, которое описано ниже.
96
Необходимо обратить внимание на то, что единственное различие между обычным
HTTP-сообщением и HTTP-сообщением межсайтовой подделки в «неявном»
методе OAuth является заголовком Referer. Клиентское приложение может
обнаруживать межсайтовую подделку запроса, проверяя домен заголовка Referer,
который является либо провайдером идентификации, который извлекается из URIперенаправления, либо собственный домен.
Обычный HTTP запрос клиентского приложения в «неявном» методе
OAuth:
GET /AIdP-callback
Host: RP.com
User-Agent: ***
Accept: ***
Accept-Language: en-US,en;q=0.5
Referer: https://AIdP.com
Cookie: ***
Ответное сообщение:
HTTP/1.1 200 OK
Date: ***
Server: ***
Last-Modified: ***
Content-Length: ***
Content-Type: text/html
Connection: Closed
HTTP межсайтовой подделки запроса в «неявном» методе OAuth:
GET /AIdP-callback
Host: RP.com
User-Agent: ***
Accept: ***
Accept-Language: en-US,en;q=0.5
Referer: https://attacker.com
97
Cookie: ***
Ответное сообщение:
HTTP/1.1 200 OK
Date: ***
Server: ***
Last-Modified: ***
Content-Length: ***
Connection: Closed
3.2 Защита OAuth от фишинга
3.2.1 Описание и архитектура модифицированной версии OAuth
По сравнению с исходным протоколом OAuth, улучшенная версия OAuth
имеет другую структуру и отличающийся процесс генерации пользовательский
данных. Эти улучшения используют надежное трёхстороннее соглашение и
одноразовая панель. Таким образом пользователи могут не вводить пароли,
которые хранятся на сервере ресурсов. Одноразовая парень использует механизм
шифрования в криптографии. В одноразовой панели, основной текст соединяется с
соответствующим битом, после которого данная конструкция шифруется. Если
ключ шифрования хорошо разработан, его будет трудно расшифровать.
Архитектура модифицированной версии OAuth показана на рисунке – 3.2.
Основываясь на идее надежного трёхстороннего соглашения, система проверки
представляет собой доверенное лицо, в котором пользователь и сервер авторизации
могут проверять друг друга.
98
Рисунок 3.2 – Система архитектуры модифицированной версии OAuth
Система проверки состоит из трех важных частей: информационный шлюз
(СМС или Email), проверочный шлюз и проверочный клиент. После получения
проверочного запроса, проверочный шлюз генерирует проверочную информацию
и сообщает информационному шлюзу отправить её по СМС или по Email.
Пользователь получает подтверждающее СМС или письмо на почту, с помощью
которых сможет подтвердить, что он является действительным пользователем.
После всех пользовательских операций с проверочной информацией, проверочный
шлюз сгенерирует пользовательские данные, которые будут отправлены серверу
авторизации для заверения авторизации.
Другим важной особенностью усовершенствованной версии OAuth
является
способ
создания
непредсказуемой
проверочной
информации
и
пользовательских данных.
В оригинальном протоколе OAuth пользовательские данные используют
идентификатор и пароль, зарегистрированные у поставщика услуг. По сравнению
99
с
OAuth,
улучшенная
версия
генерирует
проверочную
информацию
и
пользовательские данные с помощью механизма одноразовой панели. Во-первых,
проверочный шлюз создает уникальный идентификатор пользователя с номером
мобильного телефона пользователя или Email почты, которые были получены при
запросе
проверочной
информацию,
информации.
содержащую
некоторое
Во-вторых,
секретное
генерирует
значение
проверочную
для
отправки
пользователю. Пользователь возвращает секретное значение в проверочной
информации. И наконец, проверочный шлюз автоматически генерирует пароль,
который не нужно запоминать. Основные этапы описаны следующим образом:
1.
Сгенерировать идентификатор пользователя: User_ID: User_ID =
F1 (user_register_information.
2.
Сгенерировать пароль пользователя: User_PW:
User_PW
=
F2
(VR, User_ID). F2 имеет два параметра. VR значит ответ проверки, которое
является ответным сообщением пользователя проверочному шлюзу после
получения проверочной информации. User_ID это результат функции F1.
3.
Отправка User_ID и User_PW на сервер авторизации.
4.
Сервер авторизации хранит пользовательские данные.
Разница в процессе оригинального OAuth заключается в том, что
улучшенная версия OAuth добавляет дополнительный трехсторонний секретный
ключ и механизм передачи на основе трехстороннего рукопожатия.
Конкретные шаги заключаются в следующем:
1.
Клиент OAuth запрашивает у сервера аутентификации временные
данные с помощью данных клиента.
2.
После получения ответа на запрос сервер аутентификации проверяет,
является ли запрос клиента OAuth достоверным. Если проверка проходит успешно,
то сервер аутентификации возвращает временным данные, если нет возвращает
ошибочную информацию.
100
3.
После получения временных данные, клиент OAuth запрашивает
контрольную информацию (обычно пин-код) у сервера аутентификации с
помощью временных данных.
4.
После получения ответа, сервер аутентификации проверяет временные
данные и выдаёт пользователю обратный URL.
5.
Пользователь заполняет регистрационную информацию (кроме пароля
и личной информации) и отправляет её через обратный URL.
6.
После получения регистрационной информации, которая является
уникальным
идентификатором
запрашивает
проверочный
для
шлюз
пользователя,
отправить
сервер
аутентификации
проверочную
информацию
проверочному клиенту.
7.
Ответ проверки: пользователь получает проверочную информацию
(например, проверочный код, проверочная ссылка на почту).
8.
Проверочный шлюз генерирует пользовательские данные на основе
ответа пользователя и отправляет их на сервер авторизации.
9.
Сервер авторизации генерирует проверочный код OAuth и отсылает его
клиенту OAuth.
10. Клиент OAuth запрашивает токен на сервере авторизации с помощью
проверочного кода OAuth.
11. Сервер авторизации проверяет код OAuth, генерирует токен и
отправляет его клиенту OAuth. OAuth получает токен и сохраняет его.
12. Авторизация закончена.
На рисунке 3.3 представлены вышеописанные шаги авторизации.
101
Рисунок 3.3 – Последовательная диаграмма модифицированной версии OAuth
3.2.2 Оценка эффективности модифицированной версии OAuth
Чтобы оценить эффективность предлагаемого решения необходимо
использовать теоретический анализ, который будет состоять из двух этапов.
Первый этап — это описание воздействия фишинговых атак на функции
безопасности модифицированной версии OAuth. Второй этап – анализ моделей
угроз, чтобы показать, как работают контрмеры.
Здесь будет представлены некоторые функции безопасности, встроенные в
улучшенную версию OAuth.
Проверочная информация используется для обнаружения вредоносных
приложений и для предотвращения фишинговых атак. Например, типичный
102
сценарий фишинг-атаки заключается в том, чтобы заставить пользователя
поверить, что приложение злоумышленника выдает себя за клиента или сервер
авторизации. Намного проще пользователям идентифицировать особенности
проверочной информации, отправленные проверочным шлюзом, в то время как в
оригинальной OAuth информация отображается на странице авторизации. Если
фишинг-злоумышленник подделывает проверочную информацию, настоящий
проверочный
шлюз
злоумышленник
не
перехватит
может
ответ
узнать
проверки.
Между
проверочную
тем,
фишинг-
информацию
из-за
непредсказуемого значения в проверочной информации.
Ответ проверки помогает серверу авторизации предотвратить кражу
пользовательских учетных данных в следствии фишинг атаки. Проверочная
информация меняется каждый раз, и поэтому она связана с ответом на проверку, в
результате чего динамические пользовательские учетные данные генерируются
проверочным шлюзом. По сравнению с оригинальным OAuth, механизм
одноразовой панели затрудняет проведение фишинг-атак.
Пользователь, проверочный шлюз и сервер авторизации сформировали
трехстороннюю
группу
взаимно
доверительных
ключевых
соглашений.
Пользователь не взаимодействует с сервером авторизации напрямую в процессе
авторизации. Пользовательские учетные данные генерируются в результате ответа
проверки в пределах пользователя и сервера авторизации. Если какой-либо стороне
не было доверено, процесс будет прекращен.
Поддельный сервер авторизации – это самый распространенный и простой
в использовании фишинг, который оригинальный OAuth не может правильно
обрабатывать. Злоумышленник может украсть пароль пользователя или другую
информацию, различными способами заманивая его, чтобы пользователь ввел свои
учетные данные на поддельной странице авторизации.
Контрмеры модифицированной версии OAuth заключаются в следующем:
1.
Механизм ключа (проверочная информация, ответ проверки и
пользовательские
трехстороннего
учетные
соглашения
данные),
созданный
(проверочный
шлюз,
с
помощью
пользователь
надежного
и
сервер
103
авторизации), позволяет этим трем составляющим доверять друг другу. Атака
завершится неудачно, если поддельный сервер авторизации не заслуживает
доверия у проверочного шлюза.
2.
Нет никакого смысла получать ключ из механизма одноразовой панели
и важную проверочная информация, так как она является взаимодействующей
между пользователем и проверочным узлом.
Если поддельный проверочный шлюз работает, то злоумышленники могут
получить проверочный ответ от пользователя и украсть пользовательские данные.
Контрмеры модифицированной версии OAuth заключаются в следующем:
1.
Непредсказуемость проверочной информации делает переписку
сложной. Неправильная проверочная информация приводит к неправильным
пользовательским данным, мимо которой сервер авторизации не может пройти
мимо.
2.
Злоумышленник не может отменить функцию F2.
3.
Сервер авторизации отвергнет запрос от проверочного шлюза,
которого нет в белом списке.
Фишинг
злоумышленник
пользовательской
может
регистрационной
использовать
поддельный
информации,
URL,
чтобы
где
получить
регистрационную информацию пользователя (такую как телефонный номер или
другую конфиденциальную информацию).
Контрмеры модифицированной версии OAuth заключаются в следующем:
1.
Пользовательская регистрационная информация, возвращаемая через
обратный URL не должна быть конфиденциальной и необходимо избегать ввода
пароля.
2.
Атакующий не может отменить функции F1 и F2.
Фишинг пользовательских данных, где вредоносная программа может
попытаться получить данные пользователя, злоупотребляя встроенным браузером
в процессе авторизации пользователя или представляя свой собственный
пользовательский интерфейс, а не позволяя доверенным системным браузерам
отображать
пользовательский
интерфейс
авторизации.
После
того,
как
104
злоумышленник получит учетные данные пользователя, он может получить
секретный ресурс, хранящийся у владельца ресурсов.
Контрмеры модифицированной версии OAuth заключаются в следующем:
1.
Использовать TLS для любых запросов, где подлинность сервера
авторизации или подлинность запрашиваемых ответов была проблемной.
2.
Пользовательские учетные данные были динамически сгенерированы
на одноразовой панели в проверочном шлюзе и отправлены на сервер авторизации.
Этот процесс произошел внутри поставщика услуг, поэтому было сложно получить
пользовательские учетные данные.
105
ЗАКЛЮЧЕНИЕ
В ходе выполнения выпускной квалификационной работы был проведен
анализ открытого протокола OAuth, базирующегося на открытом протоколе OAuth,
открытого протокола OpenID Connect и предприняты меры по защите данных
протоколов от межсайтовой подделки запросов и фишинга:
1. Описан открытый протокол OAuth.
2. Описан открытый протокол OpenID Connect.
3. Выявлены цель, задачи и основные требования для анализа открытых
протоколов OAuth и OpenID Connect в среде ProVerif.
4. Проанализированы инструментальные средства для анализа открытых
протоколов OAuth и OpenID Connect.
5. Проанализирован открытый протокол OAuth.
6. Проанализирован открытый протокол OpenID Connect.
7. Найдены способы защиты открытых протоколов OAuth и OpenID Connect от
межсайтовой подделки запросов.
8. Найдены способы защиты открытого протокола OAuth от фишинга.
В рамках данной выпускной квалификационной работы анализ безопасности
открытого протокола OAuth в среде ProVerif считается законченным.
106
СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ
1.
Discovering concrete attacks on website authorization by formal analysis
ресурс].
[Электронный
–
Режим
доступа:
https://www.doc.ic.ac.uk/~maffeis/papers/jcs14.pdf. – Дата доступа: 12.06.2018.
2.
WebSpi and web application models [Электронный ресурс]. – Режим
доступа: http://prosecco.gforge.inria.fr/webspi/CSF/. – Дата доступа: 12.06.2018.
3.
Robust defenses for cross-site request forgery [Электронный ресурс]. –
Режим доступа: https://seclab.stanford.edu/websec/csrf/csrf.pdf. – Дата доступа:
12.06.2018.
4.
Cryptographic protocol verifer in the formal model [Электронный ресурс].
– Режим доступа: http://prosecco.gforge.inria.fr/personal/bblanche/ proverif/. – Дата
доступа: 12.06.2018.
5.
Universally composable security analysis of OAuth v2.0 [Электронный
ресурс]. – Режим доступа: https://eprint.iacr.org/2011/526.ps.gz. – Дата доступа:
12.06.2018.
6.
ресурс].
OAuth demystified for mobile application developers [Электронный
–
Режим
доступа:
https://www.microsoft.com/en-us/research/wp-
content/uploads/2016/02/OAuthDemystified.pdf. – Дата доступа: 12.06.2018.
7.
OpenID Connect Session Management [Электронный ресурс]. – Режим
доступа: http://openid.net/specs/openid-connect-session-1_0.html. – Дата доступа:
12.06.2018.
8.
The Murphi Verification System [Электронный ресурс]. – Режим
доступа: http://formalverification.cs.utah.edu/Murphi/. – Дата доступа: 12.06.2018.
9.
A comprehensive formal security analysis of OAuth [Электронный
ресурс]. – Режим доступа:
https://sec.uni-stuttgart.de/_media/publications/FettKuestersSchmitz-CCS-2016.pdf
10. Hypertext transfer protocol [Электронный ресурс]. – Режим доступа:
https://tools.ietf.org/html/rfc2616. – Дата доступа: 12.06.2018.
107
11. The OAuth authorization framework. [Электронный ресурс]. – Режим
доступа: http://tools.ietf.org/html/rfc6749. – Дата доступа: 12.06.2018.
12. Alloy
4.1
[Электронный
ресурс].
–
Режим
доступа:
http://alloy.mit.edu/community/. – Дата доступа: 12.06.2018.
13. Security issues in OAuth SSO implementations [Электронный ресурс]. –
Режим доступа:
https://www.researchgate.net/publication/312768921_Security_Issues_in_OAuth_20_S
SO_Implementations. – Дата доступа: 12.06.2018.
14. Analysing the security of Google's implementation of OpenID Connect
[Электронный ресурс]. – Режим доступа:
https://pure.royalholloway.ac.uk/portal/files/26639309/Analysing_final.pdf
–
Дата
доступа: 12.06.2018.
15. OAuth threat model and security considerations [Электронный ресурс]. –
Режим доступа: http://tools.ietf.org/html/rfc6819. – Дата доступа: 12.06.2018.
16. OWASP Foundation. Owasp top ten project [Электронный ресурс]. –
Режим доступа: https://www.owasp.org/images/f/f8/OWASP_Top_10_-_2013.pdf. –
Дата доступа: 12.06.2018.
17. Formal verification of OAuth using Alloy framework [Электронный
ресурс]. – Режим доступа:
https://webcache.googleusercontent.com/search?q=cache:0TVVZmdlNoJ:https://pdfs.semanticscholar.org/8462/7584b6fcf78c896d473b4b0e24dc089d814
b.pdf+&cd=1&hl=ru&ct=clnk&gl=ru – Дата доступа: 12.06.2018.
18. Openid connect core 1.0 [Электронный ресурс]. – Режим доступа:
http://openid.net/specs/openid-connect-core-1_0.html. – Дата доступа: 12.06.2018.
19. Securing OAuth implementations in smart phones [Электронный ресурс].
– Режим доступа:
https://sci-hub.tw/https://dl.acm.org/citation.cfm?id=2557547.2557588 – Дата доступа:
12.06.2018.
20. More guidelines than rules: CSRF vulnerabilities from noncompliant OAuth
implementations
[Электронный
ресурс].
–
Режим
доступа:
108
–
https://link.springer.com/chapter/10.1007/978-3-319-20550-2_13
Дата
доступа:
12.06.2018.
21. Murphi analysis of OAuth implicit grant flow [Электронный ресурс]. –
Режим доступа:
http://www.stanford.edu/class/cs259/WWW11/. – Дата доступа:
12.06.2018.
22. The devil is in the (implementation) details: An empirical analysis of OAuth
SSO
systems
ресурс].
[Электронный
–
Режим
доступа:
https://css.csail.mit.edu/6.858/2013/readings/oauth-sso.pdf – Дата доступа: 12.06.2018.
23. Signing Me onto Your Accounts through Facebook and Google: a TrafficGuided Security Study of Commercially Deployed Single-Sign-On Web Services
[Электронный
ресурс].
–
Режим
доступа:
https://www.microsoft.com/en-
us/research/wp-content/uploads/2012/05/websso-final.pdf – Дата доступа: 12.06.2018.
24. Model-based
implementations
security
[Электронный
testing:
An
ресурс].
empirical
–
study
on
Режим
https://staff.ie.cuhk.edu.hk/~khzhang/my-papers/2016-asiaccs-oauth.pdf
OAuth
доступа:
–
Дата
доступа: 12.06.2018.
25. Automated testing of web applications for Single Sign-On vulnerabilities
[Электронный
ресурс].
–
Режим
https://www.cs.virginia.edu/~evans/pubs/usenix2014/ssoscan.pdf
12.06.2018.
доступа:
–
Дата
доступа:
v-7
8L0a u.do
'H g sorrog
liodY.oa @€
:seraxd.s u6Mxo[
erotucoro^doH
srnno{o!,{d
:4{orenoc rc.r&roY
'oE
Y sowsu
u5E&c
[email protected]
u.^.t!o[
.bg"d 4oHHoqrHr+,@!,
rloHDlxEs r tsrew!!.rqmorlPdr.sowoY :eraow^)tov otrsssose{lEH
reHlrcrr osccorn€Hdoocr 5EHdru?doudo)I (snood!) [email protected]
ernendooHr eqi?ntsdll €o.to 60 .fiH3rJdRdulH
xrqHsotsF"ndooq! edteoe)
lllrorosxd nssorrE^doos!
9fts9r d+qrTr
.nrs no4odller€
s
',{0$n..nHHloch.odognd! Irm5ryI
! lnrE rf"noffe
Bhr&.edO{ 3Er}r1.r' Eaoresl4
Euiv{rJ
grscemer.lr-d! [email protected]{€',! tlrsHHorlE.lt.Ho^er es
gr.osYd [email protected] lolDilc^Insg )I
JJIrr 4IrmOIrd:I€OJCOtr^
9tI99I
6N
<(vrI3HsJdIl c 14 ZH!tr trI
ff[t{cdaflx{ !ffII]I{ltqJ,J.Ivtr^coJ ![DIcgoIIdo>
VI4I{YSO€VdIIO OJ!trIIcIq€MtrIarXAi&
aoHqraJvgo€ydso gotflsx[ots soH{ss.tc{'cl7^30J aoH{rrr'dlt[[email protected]
[email protected] I4olc44ccod r/Dr
rr'H
{
rrrHvrro€ydso os.rcdllJJl-ftri',{
atl
z
drry
rwdts
,7
l/67 ta
,6dr!1r
:nu.
aq*dafr'[email protected]{
N{ure kuD |sFhdotBN
.waDn,
!d.cq,lm,
a$ r€rrelurrHv
e{axrolrqo erdasodu
a
IrHesosr3wrs€ erhrueH eH
erHawlxov orosorJrar xrdisodu xerErqu^€ad
vxSvduf,
rvt4lvuuulHv
o
1/--страниц
Пожаловаться на содержимое документа