Чек-лист по OAuth. Собираем все техники атак на OAuth 2.0 и OIDC для пентеста приложений

В этой статье соб­ран перечень акту­аль­ных тех­ник тес­тирова­ния безопас­ности OAuth 2.0 и OIDC, которые мож­но исполь­зовать в тес­тирова­нии реаль­ных при­ложе­ний. Для каж­дой тех­ники будет крат­ко опи­сано, что кон­крет­но она собой пред­став­ляет, по каким приз­накам мож­но понять, что ата­ка воз­можна, и при­веден общий век­тор атак.

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

Кро­ме того, в статье не будут обсуждать­ся базовые кон­цепции про­токо­лов и основное вни­мание будет нап­равле­но на веб‑при­ложе­ния (при­ват­ные кли­енты), которые чаще все­го реали­зуют authorization code flow.

Ну и пос­леднее пре­дуп­режде­ние: статья будет рас­кры­вать тех­ники доволь­но повер­хностно и без всех деталей, потому что замысел и объ­ем матери­ала такого не под­разуме­вают. Основное вни­мание будет нап­равле­но на пок­рытие OAuth/OIDC мак­сималь­ным количес­твом дос­тупных тех­ник. По воз­можнос­ти я оставлю ссыл­ки на статьи и ресер­чи, где тема рас­кры­та глуб­же.

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

Фор­мат у спис­ков с приз­наками вос­про­изво­димос­ти такой: приз­нак наличия уяз­вимос­ти → что с этим мож­но сде­лать.

XSS

Сна­чала рас­смот­рим все слу­чаи с XSS в при­ложе­нии, которое реали­зует вход по OAuth/OIDC. Разуме­ется, речь пой­дет о ситу­ациях, ког­да сес­сия недос­тупна через JavaScript, в про­тив­ном слу­чае это game over с ATO. Здесь речь идет о перех­вате code с пос­леду­ющим обме­ном на токен.

Ес­ли в Origin кли­ент­ско­го при­ложе­ния есть XSS или дру­гой спо­соб выпол­нить про­изволь­ный JavaScript, то это сра­зу может при­вес­ти к ATO, даже если есть PKCE, потому что мы можем запус­тить флоу авто­риза­ции из родитель­ско­го окна и нам будет дос­тупен URL окна дочер­него (в котором может содер­жать­ся код авто­риза­ции).

Признаки уязвимости в OAuth + OIDC

• Есть уяз­вимость с выпол­нени­ем JS в доверен­ном Origin.
• Ис­поль­зует­ся любой response_mode (fragment, query, web message response mode), кро­ме form_post. Form_post mode не поз­воля­ет про­читать code в кли­ент­ской час­ти при­ложе­ния, code отправ­ляет­ся в теле POST-зап­роса пря­миком на callback со стра­ницы Authorization Server.

Form_post response mode — это метод отве­та в OAuth 2.0, ког­да на authorization code request authorization server отве­чает не 302 redirect с парамет­рами code/state и перенап­равле­нием на redirect_url, а 200 OK со скры­той фор­мой в сво­ем Origin, которая отправ­ляет POST-зап­рос на бэкенд кли­ента с code в теле зап­роса. Такой под­ход силь­но огра­ничи­вает кра­жу кода, но не исклю­чает его.

Общий вектор атаки, если есть XSS

Если нет PKCE

1. Най­ти воз­можность внед­рить JS в кли­ент­ском при­ложе­нии.
2. За­пус­тить OAuth/OIDC-флоу из JS (в фрей­ме или новом окне).
3. Спро­воци­ровать пре­рыва­ние OAuth-флоу у RP (смот­ри раз­дел «SSO-гад­жеты. Ата­ка Dirty Dancing»).
4. По­лучить code/token из окна или iframe с помощью JavaScript. Оди­нако­вый Origin поз­воля­ет это сде­лать.
5. Ис­поль­зовать получен­ный код для обме­на на токен или сес­сию.

Если есть PKCE