После OAuth

Разница между OAuth 1.0 и OAuth 2.0

Преж­де чем мы перей­дем к OpenID Connect, давай нем­ного отка­тим­ся назад и выяс­ним, в чем же все‑таки раз­ница меж­ду OAuth 1.0 и OAuth 2.0 и почему нам при­ходит­ся раз­бирать нес­коль­ко ите­раций про­токо­ла. Для это­го при­выч­ным обра­зом пос­мотрим флоу, на этот раз уста­рев­шего OAuth 1.0 — того самого, с которо­го все и началось в Twitter.

Приз­нать­ся чес­тно, инфу было най­ти слож­новато, так как пер­вую вер­сию очень быс­тро вытес­нил OAuth 2.0. Одна­ко чти­во реаль­но инте­рес­ное — перед под­готов­кой статьи я спра­шивал кол­лег, и ник­то из них даже и не думал о том, как работал пер­вый про­токол и почему от него отка­зались.

Здесь у нас сно­ва нем­ного изме­нил­ся ней­минг, обоз­начим все сто­роны:

1. User — это поль­зователь.
2. Consumer (пот­ребитель) — при­ложе­ние, которое хочет получить дос­туп к ресур­сам поль­зовате­ля.
3. Service Provider (пос­тавщик услуг) — при­ложе­ние, которое пре­дос­тавля­ет дос­туп к ресур­сам поль­зовате­ля.

Как мож­но с ходу заметить, сер­вера авто­риза­ции, который есть в OAuth 2.0, здесь нет.

Получение Request Token

Пер­вый зап­рос пос­ле того, как поль­зователь захотел вос­поль­зовать­ся OAuth, — от пот­ребите­ля к сер­вис‑про­вай­деру. Он нужен на пер­вом эта­пе, пос­коль­ку преж­де, чем при­ложе­ние смо­жет зап­росить авто­риза­цию у поль­зовате­ля, оно дол­жно получить токен зап­роса — Request Token. Этот токен иден­тифици­рует кон­крет­ный зап­рос авто­риза­ции, и его не получит­ся исполь­зовать для дос­тупа к ресур­сам.

Пос­коль­ку Twitter на момент написа­ния статьи все еще под­держи­вает этот про­токол, рас­смот­рим имен­но на при­мере логина в этот сер­вис. При­мер зап­роса на получе­ние рек­вест‑токена:

Все эти парамет­ры (за исклю­чени­ем oauth_callback) мы видим впер­вые. Кро­ме того, они переда­ются в Authorization-заголов­ке вмес­то при­выч­ных GET- и POST-парамет­ров. Вот за что они отве­чают:

• oauth_callback — URL, на который сер­вис‑про­вай­дер перенап­равит поль­зовате­ля пос­ле завер­шения вза­имо­дей­ствия с ним. Рань­ше такого парамет­ра не было, он появил­ся в OAuth 1.0a;
• oauth_consumer_key — иден­тифици­рует при­ложе­ние для сер­вис‑про­вай­дера. Наз­нача­ется при регис­тра­ции при­ложе­ния;
• oauth_nonce — слу­чай­ная стро­ка, уни­каль­ная для каж­дого зап­роса, нуж­на, что­бы пре­дот­вра­тить replay-ата­ки;
• oauth_signature_method — метод, с помощью которо­го под­писыва­ются отправ­ляемые дан­ные;
• oauth_timestamp — количес­тво секунд, про­шед­шее с 1 янва­ря 1970 года 00:00:00 GMT;
• oauth_version — вер­сия OAuth, которая будет исполь­зовать­ся во всем про­цес­се;
• oauth_signature — крип­тогра­фичес­кая под­пись, которая нуж­на для аутен­тифика­ции зап­роса. Авто­мати­чес­ки генери­рует­ся пот­ребите­лем на осно­ве его сек­рета.

Сам механизм под­писи доволь­но прост.

Ес­ли ты хоть нем­ного зна­ком с HMAC, то зна­ешь, что это крип­тогра­фичес­ки безопас­ная (то есть необ­ратимая) ком­бинация опре­делен­ной стро­ки с общим сек­ретом. Все отправ­ляемые дан­ные кон­катени­руют­ся, и к ним при­меня­ется HMAC с сек­ретом, который известен пот­ребите­лю и сер­вис‑про­вай­деру (oauth_consumer_secret).

В качес­тве фун­кции может исполь­зовать­ся HMAC-SHA-1, RSA-SHA-1 или любая дру­гая, которую заранее обго­ворят пот­ребитель и сер­вис‑про­вай­дер, спе­цифи­кация это не рег­ламен­тиру­ет.

Выдача неавторизованного токена OAuth

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

Здесь все­го два парамет­ра:

• oauth_token — неав­торизо­ван­ный токен OAuth. Пока он не авто­ризо­ван поль­зовате­лем, он бес­полезен. Пос­ле того как поль­зователь его авто­ризу­ет, его мож­но будет обме­нять на токен дос­тупа, или access-токен;
• oauth_callback_confirmed — флаг, уста­нов­ленный в зна­чение true, что­бы ука­зать, что сер­вис‑про­вай­дер получил URL, на который нуж­но перенап­равить поль­зовате­ля. Появил­ся в OAuth 1.0a, нужен, что­бы не допус­тить ата­ку session fixation.

Редирект пользователя на service-провайдер

Пот­ребитель не может исполь­зовать токен OAuth до тех пор, пока тот не авто­ризо­ван. Что­бы его авто­ризо­вать, он нап­равля­ет поль­зовате­ля по ссыл­ке на сер­вис‑про­вай­дер, где единс­твен­ный параметр — тот самый токен из пре­дыду­щего шага.

Бра­узер поль­зовате­ля сле­дует редирек­ту и отправ­ляет при­мер­но такой зап­рос на стра­ницу Twitter:

Аутентификация пользователя и получение согласия

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

• Сер­вис‑про­вай­дер дол­жен про­верить лич­ность поль­зовате­ля, преж­де чем зап­рашивать сог­ласие. Он может пред­ложить поль­зовате­лю вой­ти в сис­тему, если тот еще не вошел.
• Сер­вис‑про­вай­дер пре­дос­тавля­ет поль­зовате­лю информа­цию о пот­ребите­ле, который зап­рашива­ет дос­туп. Информа­ция вклю­чает в себя про­дол­житель­ность дос­тупа и ресур­сы, к которым пот­ребитель получит дос­туп.
• Поль­зователь дол­жен раз­решить или откло­нить зап­рос. Если поль­зователь отка­зыва­ет пот­ребите­лю в дос­тупе, сер­вис‑про­вай­дер не дол­жен раз­решать дос­туп к защищен­ным ресур­сам.
• Ког­да сер­вис‑про­вай­дер отоб­ража­ет информа­цию о пот­ребите­ле, он дол­жен информи­ровать поль­зовате­ля, что дан­ные, которые отоб­ража­ются, ука­заны самим пот­ребите­лем и их под­линность невоз­можно гаран­тировать (любой может наз­вать­ся при­ложе­нием «Пятероч­ки» или каким угод­но). Метод, которым он это дела­ет, в спе­цифи­кации не опре­делен.

Пос­ле того как поль­зователь под­твержда­ет дос­туп, сер­вис‑про­вай­дер воз­вра­щает его на сайт пот­ребите­ля, вмес­те с тем же токеном и парамет­ром oauth_verifier. Этот параметр появил­ся в OAuth 1.0a и явля­ется кодом верифи­кации, который мы уже зна­ем по OAuth 2.0.

Получение access-токена

Пот­ребитель получа­ет эти парамет­ры и исполь­зует уже авто­ризо­ван­ный токен, что­бы зап­росить access_token, с которым он наконец смо­жет получить дос­туп к ресур­сам.

Суть это­го зап­роса — обме­нять авто­ризо­ван­ный oauth_token на access_token.

В зап­росе отправ­ляют­ся:

• oauth_consumer_key — иден­тифици­рует при­ложе­ние для сер­вис‑про­вай­дера. Наз­нача­ется при регис­тра­ции при­ложе­ния;
• oauth_signature_method — метод под­писи отправ­ляемых дан­ных;
• oauth_signature — сама под­пись, алго­ритм генера­ции которой мы разоб­рали выше;
• oauth_timestamp — timestamp, ког­да была сге­нери­рова­на под­пись;
• oauth_token — авто­ризи­рован­ный токен, который мы обме­няем на access-токен;
• oauth_nonce — слу­чай­ная стро­ка, уни­каль­ная для каж­дого зап­роса, что­бы пре­дот­вра­тить replay-ата­ки;
• oauth_version — исполь­зуемая вер­сия OAuth.

Выг­лядит зап­рос при­мер­но сле­дующим обра­зом:

В отве­те воз­вра­щает­ся access_token — токен, с помощью которо­го мож­но получать дос­туп к ресур­сам.

Вот так:

Получение доступа к защищенным ресурсам

Пос­ле получе­ния access-токена пот­ребитель может получить дос­туп к защищен­ным ресур­сам от име­ни поль­зовате­ля. Зап­рос дол­жен быть под­писан и дол­жен содер­жать сле­дующие парамет­ры:

• oauth_consumer_key — ключ, который иден­тифици­рует пот­ребите­ля;
• oauth_token — OAuth-токен для дос­тупа к его ресур­сам;
• oauth_signature_method — метод под­писи;
• oauth_signature — под­пись зап­роса;
• oauth_timestamp — timestamp, ког­да была сге­нери­рова­на под­пись;
• oauth_nonce — слу­чай­ная стро­ка, что­бы пре­дот­вра­тить replay-ата­ки;
• oauth_version — вер­сия OAuth, которая будет исполь­зовать­ся во всем про­цес­се.

На этом флоу окон­чен.

Еще одна обоб­щающая схе­ма.

Проблемы OAuth

Глав­ные проб­лемы OAuth 1.0 и OAuth 1.0a были в слож­ности реали­зации это­го про­токо­ла, имен­но на нее и жалова­лись раз­работ­чики. Ты сам толь­ко что про­читал весь флоу и убе­дил­ся, что на всех эта­пах исполь­зует­ся мно­го крип­тогра­фии.

Кро­ме это­го, поль­зовате­ли отме­чали сле­дующее:

• по умол­чанию в OAuth 1.0 токены могут иметь бес­конеч­ный срок дей­ствия, если это не нас­тро­ено ина­че на сто­роне сер­вис‑про­вай­дера;
• от­сутс­тву­ет механизм refresh-токенов, нуж­ных, что­бы выписать новый access-токен без пов­торно­го зап­роса дан­ных авто­риза­ции у поль­зовате­ля;
• OAuth 1.0 ори­енти­рован на исполь­зование в бра­узе­ре, а не отдель­ных при­ложе­ниях;
• ме­хани­ка ско­упов никак не стан­дарти­зиро­вана (и отсутс­тву­ет на сто­роне поль­зовате­ля).

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

Как мы уже узна­ли, на сме­ну OAuth 1.0a при­шел OAuth 2.0, став­ший пол­ноцен­ным фрей­мвор­ком. Но есть еще один про­токол, который в пер­спек­тиве выг­лядит гораз­до инте­рес­нее пре­дыду­щих, пос­коль­ку еще более стан­дарти­зиро­ван и реша­ет некото­рые проб­лемы OAuth 2.0. Его сей­час мы и рас­смот­рим более деталь­но.

Знакомство с OpenID Connect

Как OpenID связан с OAuth

OpenID Connect — это стан­дарт, который рас­ширя­ет исходный про­токол авто­риза­ции OAuth и опи­сыва­ет, как пос­тро­ить поверх него логику с иден­тифика­цией и аутен­тифика­цией поль­зовате­ля.

Он был раз­работан из‑за того, что в клас­сичес­ком про­токо­ле нет аутен­тифика­ции. Клас­сичес­кий OAuth соз­дан, что­бы при­ложе­ния мог­ли выдавать друг дру­гу пол­номочия на дос­туп к ресур­сам, а не для под­твержде­ния лич­ности поль­зовате­ля.

OpenID Connect в решении с Hybrid Flow может гаран­тировать как авто­риза­цию, так и аутен­тифика­цию, что дела­ет его уни­вер­саль­ным и более совер­шенным ана­логом клас­сичес­кого OAuth, OAuth 1.0a и OAuth 2.0.

OAuth не решает задачу аутентификации

Ла­бора­тор­ная работа, которую мы решали в пер­вой статье, показы­вает это на реаль­ном при­мере. Поль­зователь при­ходит к при­ложе­нию с каким‑то токеном и говорит, что он его вла­делец. Но при­ложе­ние при этом не может про­верить, дей­стви­тель­но ли человек, который пред­ста­вил­ся ука­зан­ным токеном, тот, за кого себя выда­ет.

То­кен может быть получен через взло­ман­ное при­ложе­ние (кто‑то слил базу с токена­ми) или перенап­равле­ние на под­дель­ный сайт, который затем передаст токен зло­умыш­ленни­ку. Мы зна­ем уже мно­го спо­собов кра­жи токенов и про­вери­ли их на прак­тике.

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

То­кен OAuth по сво­ей при­роде пред­назна­чен для того, что­бы пре­дос­тавить дос­туп к ресур­сам от име­ни поль­зовате­ля. Хотя в самом токене может быть закоди­рова­на мета­информа­ция о его вла­дель­це, эта информа­ция не была пре­дос­тавле­на с целью аутен­тифика­ции и на нее нель­зя полагать­ся как на доказа­тель­ство лич­ности.

В пер­вой лабора­тории раз­работ­чики решили проб­лему собс­твен­ным спо­собом — научи­лись при­нимать email от поль­зовате­ля в качес­тве логина и OAuth-токен в качес­тве пароля. Даль­ше была валида­ция токена, но не было никакой про­вер­ки, что к ним при­шел тот поль­зователь, чей email мог ука­зать хакер. Так и воз­никла уяз­вимость, которая поз­волила вой­ти в любой чужой акка­унт.

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

Мо­гут воз­никнуть воп­росы, нап­ример: «Может быть, спро­сить у поль­зовате­ля, какой email был ука­зан у вла­дель­ца токена? Или нуж­но уточ­нить его номер телефо­на с кодовым сло­вом, которые знал бы толь­ко соз­датель акка­унта на сер­вере ресур­сов?» Но все это не поз­воля­ет точ­но аутен­тифици­ровать поль­зовате­ля.

Кро­ме того, для над­лежащей под­дер­жки OAuth кли­ент­ским при­ложе­ниям приш­лось бы нас­тра­ивать отдель­ные механиз­мы для каж­дого про­вай­дера, каж­дый с раз­ными эндпо­инта­ми, уни­каль­ными набора­ми ско­упов и так далее.

OpenID Connect реша­ет мно­гие проб­лемы, добав­ляя стро­гую стан­дарти­зацию, что­бы сде­лать аутен­тифика­цию через OAuth надеж­ной, прос­той и еди­нооб­разной.

Кро­ме того, он пос­тро­ен на базе обыч­ного OAuth, бла­года­ря это­му на него лег­ко перей­ти.

Принцип работы OpenID Connect

Для начала уточ­ним тер­миноло­гию. OpenID Connect вво­дит нес­коль­ко клю­чевых тер­минов, нез­накомых по обыч­ному OAuth. Вот они:

• Relying Party (RP) — это при­ложе­ние, которое зап­рашива­ет аутен­тифика­цию поль­зовате­ля. Синоним обыч­ного OAuth Client Application.
• Identity Provider (IdP) или OpenID Provider (OP) — это служ­ба, которая аутен­тифици­рует поль­зовате­лей и пре­дос­тавля­ет информа­цию про­веря­ющим сто­ронам (RP) или кли­ент­ским при­ложе­ниям. Отве­чает за про­вер­ку лич­ности поль­зовате­ля.
• End-User — поль­зователь, который вза­имо­дей­ству­ет с самим при­ложе­нием и Identity-про­вай­дером. Синоним Resource Owner из клас­сичес­кого OAuth.
• Identity Token (ID Token) — JWT-токен, который выписы­вает Identity Provider пос­ле успешной аутен­тифика­ции. В него закоди­рова­на информа­ция об аутен­тифици­рован­ном поль­зовате­ле, вклю­чая его ID и имя. Identity-токен — это основное рас­ширение для аутен­тифика­ции через OAuth 2.0.
• Claims — атри­буты конеч­ного поль­зовате­ля в фор­мате ключ: значение вро­де first_name: Ivan.

Hybrid Flow

Для начала прос­тая кар­тинка.

А теперь более слож­ная и более под­робная.

OpenID под­держи­вает Client Credentials Grant, Resource Owner Password Grant, Implicit Flow и Hybrid Flow. Рас­смот­рим флоу аутен­тифика­ции Hybrid Flow, который ком­биниру­ет эле­мен­ты Authorization Code Flow и Implicit Flow из OAuth 2.0:

1. Authentication Request. Про­веря­ющая сто­рона (Relying Party) ини­циирует зап­рос аутен­тифика­ции, нап­равляя бра­узер поль­зовате­ля OpenID-про­вай­деру (OpenID Provider).
2. Authentication. Про­вай­дер OpenID аутен­тифици­рует поль­зовате­ля. Этот про­цесс может раз­личать­ся в зависи­мос­ти от про­вай­дера, но обыч­но он вклю­чает зап­рос учет­ных дан­ных поль­зовате­ля и их про­вер­ку.
3. Authorization Code. Пос­ле аутен­тифика­ции поль­зовате­ля про­вай­дер OpenID перенап­равля­ет бра­узер поль­зовате­ля обратно про­веря­ющей сто­роне с кодом авто­риза­ции.
4. Token Request. Про­веря­ющая сто­рона обме­нива­ет этот код авто­риза­ции на identity-токен и access-токен.
5. Token Verification. Identity Token — это JWT-токен, в котором хра­нит­ся информа­ция об аутен­тифика­ции конеч­ного поль­зовате­ля. Про­веря­ющая сто­рона про­веря­ет этот токен, что­бы убе­дить­ся в его дей­стви­тель­нос­ти и получить информа­цию о поль­зовате­ле.

Как мож­но заметить, бег­ло про­читав эти пун­кты, в обыч­ном OAuth воз­вра­щает­ся толь­ко access-токен, в OpenID еще воз­вра­щает­ся identity-токен, наличие которо­го под­твержда­ет, что поль­зователь аутен­тифици­ровал­ся.

Вто­рое отли­чие зак­люча­ется в ско­упах. На эта­пе Authentication Request в парамет­ре scope всег­да отправ­ляет­ся зна­чение openid, а пос­ле него сле­дуют области дан­ных, к которым при­ложе­ние хочет получить дос­туп, нап­ример scope=openid profile email phone. Это не обыч­ные ско­упы, а клей­мы, за каж­дым из которых может быть зак­репле­но нес­коль­ко атри­бутов.

Кро­ме того, если в базовом OAuth каж­дый сер­вер авто­риза­ции ука­зывал собс­твен­ный набор полей, то в OpenID спи­сок полей у всех про­вай­деров уни­фици­рован и опи­сан в спе­цифи­кации.

И третье отли­чие зак­люча­ется в наличии трех обя­затель­ных эндпо­интов:

• Authorization;
• Token;
• UserInfo.

А так­же опци­ональ­ных:

• WebFinger;
• Provider metadata;
• Provider JWK set;
• Client registration;
• Session management.

Один из них мы рас­смот­рим далее более под­робно.

Что зашито в Identity Token

Наг­лядное срав­нение identity-токена и access-токена мож­но пос­мотреть на кар­тинке ниже.

Мы не будем под­робно раз­бирать access-токен, потому что и так о нем уже дос­таточ­но зна­ем и работа­ли с ним на прак­тике. Важ­но раз­личать токены и знать, что access-токен исполь­зует­ся для получе­ния дан­ных о поль­зовате­ле от про­вай­дера OpenID, а ID — для его аутен­тифика­ции про­веря­ющей сто­роной. Поэто­му прис­таль­нее раз­берем Identity Token.

Identity Token мож­но вос­при­нимать как удос­товере­ние лич­ности, которое под­писано про­вай­дером OpenID. Что­бы его получить, кли­ент дол­жен быть аутен­тифици­рован.

Осо­бен­ности identity-токена:

• под­твержда­ет лич­ность поль­зовате­ля, который называ­ется субъ­ектом в OpenID (sub);
• ука­зыва­ет на орган, который его выписал (iss);
• ге­нери­рует­ся для опре­делен­ной ауди­тории, то есть кли­ента (aud);
• мо­жет содер­жать крип­тогра­фичес­кий nonce для пре­дот­вра­щения replay-атак;
• мо­жет ука­зывать, ког­да (auth_time) и как (acr) поль­зователь был аутен­тифици­рован;
• ука­зыва­ет, ког­да был выписан токен (iat) и каков срок его дей­ствия (exp);
• мо­жет вклю­чать допол­нитель­ные све­дения о субъ­екте, такие как имя и адрес элек­трон­ной поч­ты;
• име­ет циф­ровую под­пись, поэто­му его может про­верить пред­полага­емый получа­тель;
• мо­жет быть допол­нитель­но зашиф­рован для кон­фиден­циаль­нос­ти.

Identity-токен может быть упа­кован в прос­той объ­ект JSON:

Этот объ­ект зашит в JWT, который закоди­рован в Base64.

Под­робнее о струк­туре дан­ных JWT и ее кодиров­ке мож­но про­читать в RFC 7519, а об ата­ках на JWT — в мо­ей пре­дыду­щей статье.

OpenID Connect Discovery

OpenID Connect Discovery (он же WebFinger) — это механизм, который поз­воля­ет узнать всю необ­ходимую информа­цию о про­вай­дере OpenID, что дает воз­можность интегри­ровать с ним целевое при­ложе­ние, или Relying Party, как оно называ­ется в OpenID.

OpenID Connect Discovery пре­дос­тавля­ет метадан­ные кон­фигура­ции про­вай­дера, вклю­чая:

• URL для авто­риза­ции (authorization_endpoint);
• URL для получе­ния токенов (token_endpoint);
• URL для получе­ния информа­ции о поль­зовате­ле (userinfo_endpoint);
• под­держи­ваемые токены и алго­рит­мы;
• под­держи­ваемые клей­мы (нап­ример, sub, name, email);
• ме­тадан­ные для про­вер­ки под­писи токенов (jwks_uri) и дру­гие важ­ные дан­ные.

Рас­полага­ется обыч­но по такому адре­су:

И воз­вра­щает JSON со всей необ­ходимой информа­цией:

Обыч­но этот эндпо­инт может дать мно­го полез­ной информа­ции как для раз­работ­чика, который интегри­рует OpenID в собс­твен­ный сайт, так и для хакера.

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

Незащищенная динамическая регистрация клиента

Как ты пом­нишь, пер­вым эта­пом в OAuth и OpenID, незави­симо от того, какой про­токол исполь­зует­ся, была регис­тра­ция самого при­ложе­ния или про­веря­ющей сто­роны.

Спе­цифи­кация OpenID Connect опи­сыва­ет стан­дарти­зиро­ван­ный спо­соб, который поз­воля­ет кли­ент­ским при­ложе­ниям регис­три­ровать­ся у про­вай­дера OpenID с помощью выделен­ного для это­го эндпо­инта. Это удоб­но и эко­номит вре­мя, потому что для это­го не тре­бует­ся соз­давать отдель­ный лич­ный кабинет.

Ес­ли под­держи­вает­ся динами­чес­кая регис­тра­ция кли­ента, про­веря­ющая сто­рона может зарегис­три­ровать­ся, отпра­вив спе­циаль­но сфор­мирован­ный POST-зап­рос на выделен­ный registration_endpoint, нап­ример /registration. Путь может отли­чать­ся, и обыч­но он ука­зыва­ется в фай­ле с нас­трой­ками или в докумен­тации.

В теле зап­роса кли­ент­ское при­ложе­ние отправ­ляет клю­чевую информа­цию о себе в фор­мате JSON. Нап­ример, час­то в качес­тве обя­затель­ных полей выс­тупа­ют имя при­ложе­ния, его URL, а так­же спи­сок раз­решен­ных URI для перенап­равле­ния. Типич­ный зап­рос на регис­тра­цию выг­лядит при­мер­но так:

Про­вай­дер OpenID дол­жен пот­ребовать от про­веря­ющей сто­роны прой­ти аутен­тифика­цию. В при­мере выше для это­го исполь­зует­ся bearer-токен ab12cd34ef56gh89. Одна­ко некото­рые про­вай­деры раз­реша­ют динами­чес­кую регис­тра­цию кли­ентов без какой‑либо аутен­тифика­ции, что поз­воля­ет зло­умыш­ленни­ку регис­три­ровать свое вре­донос­ное при­ложе­ние.

Пос­ледс­твия могут быть раз­ными в зависи­мос­ти от того, как исполь­зуют­ся зна­чения этих кон­тро­лиру­емых зло­умыш­ленни­ком свой­ств самим про­вай­дером. Нап­ример, ты мог заметить, что некото­рые из этих свой­ств пред­полага­ют ука­зание URI. Если про­вай­дер OpenID пыта­ется обра­тить­ся к одно­му из них, это может потен­циаль­но при­вес­ти к уяз­вимос­тям типа SSRF, если не при­нять допол­нитель­ные меры безопас­ности.

Лаба: SSRF via OpenID dynamic client registration

• Ла­бора­тор­ная работа на сай­те PortSwigger

От­кры­ваем блог, где на кар­тинке, кажет­ся, изоб­ражен читатель, который, уто­пая в цен­ной инфе, про­сит меня оста­новить­ся и закон­чить уже наконец статью. Кре­пись, оста­лось сов­сем нем­ного!

Ло­гиним­ся, как мы делали это и рань­ше. Здесь сто­ит упо­мянуть инте­рес­ный факт, на который ты мог обра­тить вни­мание при дол­жном изу­чении деталей: во всех лабора­тори­ях, которые мы решали до это­го, исполь­зовал­ся OpenID.

Пос­коль­ку и здесь исполь­зует­ся OpenID, а лабора­тория пос­вящена поис­ку уяз­вимос­тей с помощью механиз­ма Discovery, про­веря­ем все­воз­можные дирек­тории на наличие кон­фигов. Спус­тя некото­рое вре­мя находим такую пап­ку у про­вай­дера OpenID:

Здесь есть раз­ные парамет­ры, такие как уже упо­мяну­тые под­держи­ваемые клей­мы и эндпо­инты под раз­ные нуж­ды, но нас инте­ресу­ет registration_endpoint.

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

И это логич­но, пос­коль­ку мы хотим не получить какую‑то информа­цию (был бы метод GET), а зарегис­три­ровать при­ложе­ние, то есть отпра­вить какие‑то парамет­ры, которые дол­жны лечь в его осно­ву.

Пе­рехо­дим в Burp Suite и меня­ем метод с GET на POST. Вмес­то того что­бы перепи­сывать руками, мож­но прос­то клик­нуть пра­вой кноп­кой мыши и выб­рать Change request method.

От­прав­ляем зап­рос и встре­чаем новую ошиб­ку. Сер­вер ожи­дает от нас Content-Type: application/json вмес­то application/x-www-form-urlencoded, который мы отпра­вили.

Это JSON API. Меня­ем Accept на application/json. И Content-Type, что­бы ска­зать сер­веру о том, что мы отпра­вим ему объ­ект JSON. Пос­коль­ку пока что мы прос­то тес­тиру­ем этот эндпо­инт, что­бы изба­вить­ся от оши­бок, дос­таточ­но будет не ука­зывать парамет­ры и отпра­вить зап­рос пус­тым.

Встре­чаем ошиб­ку invalid_redirect_uri. Как ты пом­нишь, мы дол­жны ука­зать допус­тимые урлы, на которые сер­вер OpenID дол­жен уметь перенап­равлять поль­зовате­ля. На один параметр redirect_uri сер­вер выда­ет ошиб­ку, поэто­му отправ­ляем спи­сок из того же самого тес­тового урла с помощью redirect_uris.

Зап­рос наконец‑то выпол­нился. Это­го парамет­ра ока­залось дос­таточ­но, что­бы сра­зу зарегис­три­ровать пол­ноцен­ное при­ложе­ние даже без ука­зания его име­ни и дру­гих атри­бутов.

На сам webhook.site мож­но не обра­щать вни­мания, я пыта­юсь ука­зывать его вез­де. Но в этот раз ожи­даемо отстук, конеч­но же, не при­шел на этот URL, поэто­му нуж­но искать дру­гие парамет­ры, которые помог­ли бы нам про­экс­плу­ати­ровать SSRF.

От­прав­ляем­ся на стра­ницу Consent Screen (что­бы най­ти уяз­вимость, мне пот­ребова­лось вре­мя, поэто­му тут я решил перей­ти сра­зу к сути).

В коде при­меча­телен логотип при­ложе­ния, в которое мы вхо­дим.

При редирек­те мож­но най­ти ссыл­ку на изоб­ражение. Это логотип, который был уста­нов­лен в про­цес­се регис­тра­ции при­ложе­ния.

Ло­го зап­рашива­ется через спе­циаль­ный ID и, что самое глав­ное, хра­нит­ся на сер­вере про­вай­дера OpenID. Это стран­но, ведь если кли­ент­ское при­ложе­ние регис­три­рова­лось с собс­твен­ным URL, то тут дол­жен был бы ока­зать­ся он, а не ссыл­ка на про­вай­дер.

Здесь мож­но пред­положить, что про­вай­дер ходит по пре­дос­тавлен­ной ссыл­ке, ска­чива­ет изоб­ражение и сох­раня­ет его у себя, отда­вая в даль­нейшем его с собс­твен­ного сер­вера. Обыч­но в таких мес­тах и воз­ника­ют SSRF-уяз­вимос­ти.

Мы можем попытать­ся отпра­вить зап­рос, что­бы убе­дить­ся, что это дей­стви­тель­но логотип кли­ент­ско­го при­ложе­ния, который хос­тится у про­вай­дера OpenID.

От­кры­ваем спе­цифи­кацию и чи­таем о динами­чес­кой регис­тра­ции собс­твен­ного при­ложе­ния с помощью OpenID. Дей­стви­тель­но, находим параметр, который отве­чает за логотип.

Поп­робу­ем сно­ва зарегис­три­ровать собс­твен­ное при­ложе­ние и ука­зать в качес­тве URL для логоти­па тот сер­вер, к которо­му нам нуж­но обра­тить­ся по заданию:

При­ложе­ние успешно соз­дано, но пока что это Blind SSRF или не SSRF вов­се, пос­коль­ку ответ пос­мотреть мы не можем, а веб‑хук, который я про­бовал ука­зывать до это­го, в этом поле тоже не сра­баты­вает. Либо нам сно­ва надо искать новый параметр, либо PortSwigger отклю­чает в сво­их вир­туаль­ных машинах интернет, что­бы усложнить жизнь реаль­ным зло­умыш­ленни­кам.

Об­раща­емся к кар­тинке:

Та часть, которая находит­ся меж­ду /client/ и /logo, — это ID при­ложе­ния. Поэто­му, что­бы уви­деть наше лого, в качес­тве которо­го мы ука­зали внут­ренний сер­вер, нуж­но заменить этот ID иден­тифика­тором того при­ложе­ния, которое мы бук­валь­но толь­ко что зарегис­три­рова­ли.

Вот мы и получи­ли токен адми­нис­тра­тора. Про­вай­дер OpenID попытал­ся заг­рузить нашу кар­тинку, отпра­вил зап­рос в свою внут­реннюю сеть (на тот URL, который мы ука­зали) и вер­нул содер­жимое пос­ле того, как мы зап­росили его.

Те­перь оста­ется толь­ко сдать его и при­нять поз­драв­ления. Мы всё прош­ли!

Чек-лист проверок

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

Этот драфт называ­ется OAuth 2.0 Security Best Current Practice, он был опуб­ликован 3 июня 2024 года и содер­жит меры по пос­тро­ению защиты при исполь­зовании это­го про­токо­ла.

Здесь есть мно­го момен­тов, которые мы не рас­смот­рели, поэто­му советую озна­комить­ся с докумен­том OAuth 2.0 Security Best Current Practice.

Риски

Да­вай под конец вкрат­це прой­дем­ся по проб­лемным нас­трой­кам, ошиб­кам прог­раммис­тов и про­чим лазей­кам и тех­никам, которые могут помочь хакерам, если при­ложе­ние исполь­зует OAuth или OpenID.

• Не­дос­таточ­ная про­вер­ка URI перенап­равле­ния: как про­веря­ется параметр redirect_uri — срав­нива­ется пол­ный адрес или толь­ко вхож­дение опре­делен­ного пути? Если выпол­няет­ся недос­таточ­ная про­вер­ка, это может при­вес­ти к кра­же access-токена.
• Утеч­ка дан­ных через заголов­ки Referer: содер­жимое зап­роса или отве­та авто­риза­ции может быть неп­редна­мерен­но рас­кры­то в заголов­ке Referer.
• Утеч­ка учет­ных дан­ных через исто­рию бра­узе­ра: ссыл­ки с кодами авто­риза­ции могут уте­кать в исто­рию бра­узе­ра.
• Mix-Up-ата­ки: ата­ки с получе­нием кода авто­риза­ции или access-токена, ког­да исполь­зует­ся два сер­вера авто­риза­ции, один из которых находит­ся под кон­тро­лем зло­умыш­ленни­ка.
• Инъ­екция кода авто­риза­ции: зло­умыш­ленник пыта­ется внед­рить укра­ден­ный код авто­риза­ции в свой сеанс с кли­ентом. Цель сос­тоит в том, что­бы свя­зать сеанс зло­умыш­ленни­ка на кли­енте с ресур­сами или лич­ностью жер­твы.
• Инъ­екция access-токена: зло­умыш­ленник исполь­зует укра­ден­ный токен, что­бы выдать себя за его вла­дель­ца.
• Cross Site Request Forgery: ата­ки типа CSRF в кон­тек­сте OAuth, поз­воля­ющие выпол­нить дей­ствие от име­ни дру­гого поль­зовате­ля (нап­ример, при­вязать свой соци­аль­ный акка­унт к чужому лич­ному акка­унту на сай­те).
• Утеч­ка access-токенов на сер­вере ресур­сов: такое слу­чает­ся, нап­ример, при взло­ме базы дан­ных.
• Утеч­ка сек­рета кли­ента: поз­волит перех­ватить коды авто­риза­ции и исполь­зовать их для обме­на на access-токены самос­тоятель­но.
• 307-й редирект: если сер­вер авто­риза­ции перенап­равля­ет на redirect_uri с кодом 307 вмес­то кода 302, сра­зу пос­ле того, как поль­зователь вво­дит свои учет­ные дан­ные, зло­умыш­ленник с собс­твен­ным вре­донос­ным при­ложе­нием может украсть учет­ные дан­ные поль­зовате­ля.
• Прок­си‑сер­вер, завер­шающий TLS-соеди­нения: ата­ки на прок­си‑сер­вер, который находит­ся перед сер­вером авто­риза­ции, с кас­томны­ми заголов­ками.
• Вы­дача себя за вла­дель­ца ресур­са: если при­ложе­ние может выб­рать client_id во вре­мя регис­тра­ции, это может при­вес­ти к кра­же чужого сек­рета.
• Clickjacking: зап­рос авто­риза­ции под­вержен ата­ке через под­мену объ­екта на стра­нице на сто­роне кли­ента. Зло­умыш­ленник может исполь­зовать этот век­тор, что­бы получить дан­ные аутен­тифика­ции поль­зовате­ля и исполь­зовать их для дос­тупа к ресур­сам.

Проверки

Ес­ли ты внед­ряешь OAuth в свой про­дукт, обра­ти вни­мание на сле­дующие момен­ты.

• OAuth исполь­зует­ся для аутен­тифика­ции (про­верить реали­зацию: мно­гие авто­риза­цион­ные сер­веры не верифи­циру­ют дан­ные, которые ука­зал поль­зователь).
• redirect_uri про­веря­ет допус­тимые URL-адре­са.
• Про­вер­ки redirect_uri нель­зя обой­ти с open redirect и path traversal.
• Исполь­зует­ся параметр state, что­бы пре­дот­вра­тить CSRF-ата­ки.
• Парамет­ры, в которых переда­ется URL (нап­ример, при регис­тра­ции при­ложе­ния), не под­верже­ны ата­кам типа SSRF.
• Для регис­тра­ции сво­его при­ложе­ния тре­бует­ся авто­риза­ция.
• Сер­вер авто­риза­ции срав­нива­ет тот ско­уп, который при­ложе­ние ука­зало при регис­тра­ции, с тем, который исполь­зует­ся при обме­не кода авто­риза­ции на access-токен.
• Код авто­риза­ции дос­таточ­но длин­ный, что­бы его нель­зя было переб­рать брут­форсом.
• Раз­ные веб‑при­ложе­ния, которы­ми вла­деет один и тот же сер­вер ресур­сов, про­веря­ют ско­упы токена преж­де, чем выдать дан­ные.

Автоматизация

Не сущес­тву­ет ути­литы, которая иска­ла бы все опи­сан­ные выше мис­конфи­гура­ции. Кро­ме того, некото­рые про­вер­ки слиш­ком слож­но авто­мати­зиро­вать. Но для самых рас­простра­нен­ных кей­сов сущес­тву­ет рас­ширение для Burp Suite, которое их пок­рыва­ет.

OAUTHScan выпол­няет про­вер­ки безопас­ности OAuth и OpenID на осно­ве информа­ции, которая опи­сана в спе­цифи­каци­ях и стать­ях, ука­зан­ных ниже:

• RFC 6749: The OAuth 2.0 Authorization Framework;
• RFC 6819: OAuth 2.0 Threat Model and Security Considerations;
• RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage;
• OAuth 2.0 Security Best Current Practice (draft);
• OAuth 2.0;
• What is OpenID Connect;
• OpenID Connect Core 1.0;
• OAuth 2.0 authentication vulnerabilities (PortSwigger);
• OpenID Connect (PortSwigger).

Вот непол­ный спи­сок про­верок, которые выпол­няет рас­ширение:

• open redirect в парамет­ре redirect_uri;
• replay-ата­ки с кодом авто­риза­ции;
• утеч­ка сек­ретов (токенов и кодов);
• неп­равиль­ная нас­трой­ка парамет­ра nonce;
• неп­равиль­ная нас­трой­ка парамет­ра state;
• об­наруже­ние OAuth-флоу, которые приз­наны небезо­пас­ными;
• по­иск SSRF через параметр request_uri;
• об­наруже­ние ресур­сов Well-Known и WebFinger.

Что­бы уста­новить OAUTHScan, надо кло­ниро­вать ре­пози­торий:

Те­перь перехо­дим в пап­ку oauth-scan и собира­ем про­ект с помощью gradlew build fatJar.

За­тем нуж­но перей­ти в Burp → Extensions, нажать на Add и выб­рать соб­ранный JAR.

Кро­ме того, его мож­но най­ти на вклад­ке BApp Store.

Уч­ти, что для при­мене­ния пла­гина нуж­на куп­ленная вер­сия Burp, в которой работа­ет Scanner, а не бес­плат­ная Community Edition без него.

Как защититься

Бла­года­ря гиб­кости про­токо­ла OAuth мож­но наделать мно­го оши­бок. Нес­мотря на то что с момен­та соз­дания пер­вой вер­сии прош­ло мно­го вре­мени и уже успе­ли появить­ся более совер­шенные OAuth 2.0 и OpenID, их исполь­зование все еще не стра­хует от оши­бок — и все зависит от раз­работ­чика, который пишет конеч­ную логику.

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

Важ­но отме­тить, что уяз­вимос­ти могут воз­никнуть как на сто­роне кли­ент­ско­го при­ложе­ния, так и на сто­роне сер­вера авто­риза­ции и сер­вера ресур­сов. Даже если твоя реали­зация надеж­на, это не зна­чит, что на том кон­це всё обе­зопа­сили.

Я перечис­лю лишь основные спо­собы защитить свое при­ложе­ние от атак, которые мы рас­смот­рели на про­тяже­нии трех ста­тей. В реаль­нос­ти век­торов нам­ного боль­ше, и о каж­дом мож­но было бы написать отдель­ный матери­ал.

Сервис-провайдерам

Ес­ли ты пре­дос­тавля­ешь авто­риза­цию OAuth или OpenID, вот нес­коль­ко полез­ных советов, которые защитят тво­их поль­зовате­лей:

• Тре­буй от кли­ент­ских при­ложе­ний регис­тра­ции белого спис­ка допус­тимых redirect_uris. По воз­можнос­ти исполь­зуй стро­гое побай­товое срав­нение для про­вер­ки URI во всех вхо­дящих зап­росах. Раз­решай толь­ко пол­ные и точ­ные сов­падения, а не исполь­зуй сопос­тавле­ние с шаб­лоном. Это поможет защитить­ся от некото­рых атак с под­делкой redirect_uri и кра­жей токена.
• При­нуди­тель­но исполь­зуй параметр state. Его зна­чение дол­жно быть при­вяза­но к сеан­су поль­зовате­ля путем вклю­чения некото­рых неуга­дыва­емых, спе­цифич­ных для сеан­са дан­ных, таких как хеш, содер­жащий сеан­совый cookie. Это помога­ет защитить поль­зовате­лей от атак типа CSRF и зна­читель­но зат­руднит зло­умыш­ленни­ку исполь­зование любых укра­ден­ных кодов авто­риза­ции.
• На сер­вере ресур­сов убе­дись, что токен дос­тупа был выдан тому же client_id, который дела­ет зап­рос. Советую так­же про­верять зап­рашива­емый ско­уп, что­бы убе­дить­ся, что он соот­ветс­тву­ет тому же ско­упу, для которо­го токен был изна­чаль­но пре­дос­тавлен.

Клиентским приложениям

А вот советы на слу­чай, если ты пишешь кли­ент­ское при­ложе­ние:

• Убе­дись, что ты пол­ностью понима­ешь детали работы OAuth, преж­де чем внед­рять его. Мно­гие уяз­вимос­ти выз­ваны прос­тым непони­мани­ем того, что имен­но про­исхо­дит на каж­дом эта­пе и как это может быть потен­циаль­но исполь­зовано.
• Ис­поль­зуй параметр state, даже если он не явля­ется обя­затель­ным.
• От­прав­ляй параметр redirect_uri не толь­ко в эндпо­инт /authorization, но и в /token.
• При раз­работ­ке мобиль­ных или собс­твен­ных кли­ент­ских при­ложе­ний OAuth для ПК час­то невоз­можно оста­вить client_secret тай­ным. В таких ситу­ациях мож­но исполь­зовать механизм PKCE (RFC 7636) для обес­печения допол­нитель­ной защиты от перех­вата или утеч­ки кода дос­тупа.
• Ес­ли ты исполь­зуешь id_token в OpenID Connect, убе­дись, что он пра­виль­но про­верен в соот­ветс­твии со спе­цифи­каци­ями JSON Web Signature, JSON Web Encryption и OpenID.
• Будь осто­рожен с кодами авто­риза­ции — они могут быть переда­ны через заголов­ки Referer при заг­рузке внеш­них изоб­ражений, скрип­тов или содер­жимого CSS. Так­же важ­но не вклю­чать их в динами­чес­ки генери­руемые фай­лы JavaScript, пос­коль­ку они могут выпол­нять­ся из внеш­них доменов через теги <script>.

Выводы

На этом мы закан­чива­ем цикл из трех ста­тей про OAuth. Теперь ты без тру­да смо­жешь отве­тить на воп­росы о том, чем отли­чает­ся OAuth пер­вой вер­сии от вер­сии 2.0, почему появил­ся OpenID Connect, сколь­ко все­го было ите­раций про­токо­ла и как это все работа­ет.

Бла­года­ря получен­ным зна­ниям ты смо­жешь сам находить уяз­вимос­ти и даже зна­ешь, как от них защитить­ся. Что­бы ничего не забыть, можешь вос­поль­зовать­ся чек‑лис­том, которой я оста­вил в статье, а что­бы не тра­тить мно­го вре­мени — рас­ширени­ями для авто­мати­зации.

На­деюсь, вся инфа была полез­на. Я попытал­ся соб­рать толь­ко самое важ­ное, но даже так это рас­тянулось на нес­коль­ко час­тей.