401 Unauthorized: аутентификация и не только

OAuch OAuch - это open-source инструмент, проверяющий соблюдение лучших практик в области безопасности для OAuth 2.0/OIDC-совместимых IdP (читай - authorization server), тем самым подсвечивая актуальные угрозы. Он должен проверять совместимость IdP с самим OAuth-фреймворком, а также насколько IdP реализует указанные разной степени обязательности практики и из ряда других документов. У авторов есть несколько опубликованных исследований, решил их изучить. Первая по хронологии статья - это “OAuch: Exploring Security Compliance in the OAuth 2.0 Ecosystem”, опубликована она была еще осенью 2022 года, а учитывая, что авторы предоставляли срок в 1 год для исправления уязвимостей, само исследование было проведено как минимум годом ранее. Это первая работа от авторов, в которой они выполняют исследование публичных IdP, а также описывают сам инструмент и принципы, на которых основана его работа. Авторы поставили довольно амбициозную цель - улучшение OAuth-ландшафта за счет проведения аудита публичных IdP на предмет соответствия рекомендациям OAuth в части информационной безопасности с дальнейшим предоставлением результатов разработчикам IdP. Авторы взяли для исследования 100 публично доступных IdP, выделив 75 из первых 10 000, а оставшиеся 25 - из первого 1 000 000 списка доступных API в ProgrammableWeb (проект в 23 году закрылся). Модель угроз основана на RFC 6819, но с некоторым расширением. OAuch предполагает наличие тест-кейсов в соответствие рекомендациям, так в исследовании участвовало 113 тестов. Кстати, авторы отмечают, что документы-спецификации описаны достаточно точно и четко, поэтому создание тест-кейсов на их основе не было очень сложным. Подчеркивается, что OAuch проверяет только сами IdP, и не учитывает угрозы для RP, а также некоторые уязвимости, которые могут быть актуальны, но не относятся к OAuth. Интересны результаты, показывающие использование различных authorization grants. Так, например, 94% IdP поддерживали authorization code grant и только 1% - device code grant (хотя авторы отмечают, что 1% в данном случае - не совсем точное значение). Вообще анализ показал, что 97/100 IdP имели хотя бы одну незакрытую угрозу (однако от себя тут добавлю, что некоторые кейсы выглядят несколько специфично). И соответственно ни один IdP не прошел полную проверку в понимании авторов. Пишут, что в среднем IdP не реализовывали 20% от обязательных рекомендаций из спецификаций и 33% от всех рекомендаций. Также отмечается, что рекомендации из Best Current Practices (BCP), а не из основного документа OAuth 2.0 имели почти в три раза (!) меньшую вероятность имплементации. Так что, возможно, что идея сведения всех спецификаций в один гигадокумент OAuth 2.1 и имеет свой смысл. Хотя, буду честен: текущий далеко не полный черновик уже имеет время прочтения более 2 часов. При всей моей вере в человечество, мне трудно представить, что от сведения всего в один документ сильно больше людей его внимательно станут изучать… Очень интересно было узнать, что на момент проведения исследования только 21% IdP поддерживали PKCE. А строгое сравнение зарегистрированных URL для redirect URI выполняли только 53% IdP… Также авторы отмечают очень интересную мысль, с которой я согласен:

RP cannot be expected to make the best security decisions

Следовательно, IdP в таком случае имеет бОльшую ответственность в том числе в предъявлении строгих требований к RP, чтобы у тех было меньше шансов выстрелить себе в ногу. В итоге авторы приходят к выводу, что… OAuth-экосистема находилась в довольно плачевном состоянии, и многие IdP не реализовывали критичные меры защиты. Также в ряде случаев разработчики были в курсе, что они не соблюдают защитные меры, однако по ряду причин (в статье они перечислены) тем не менее продолжали жить с этим. Далее мы посмотрим на следующую статью авторов, где они провели повторный анализ два года спустя, чтобы узнать, что же изменилось за это время. Кстати, если кто-то уже пробовал использовать OAuch на практике, напишите, интересно узнать реальные отзывы. #security #oauth #paper

Упрощение повторной аутентификации в PWA (часть 2) Предыдущий пост закончили на применении отдельного PIN и passkeys. Попробуем наглядно это рассмотреть, взяв для примера Сбербанк Онлайн. Клиентская часть Сбербанк Онлайн как раз выполнена в виде PWA, вот их манифест. Собственно, после первичной аутентификации пользователя Сбербанк Онлайн предлагает создать код (PIN) для данного устройства, с помощью которого можно будет выполнять аутентификацию далее. ——— 🖼 Скриншоты в посте добавлены в порядке упоминания в тексте. ——— ➡️При аутентификации с помощью кода отправляется запрос /pin/begin (скриншот 1). ➡️За ним следует запрос /pin/logon (скриншот 2). ➡️И затем уже выполняется запрос к /app/auth, в результате которого серверная часть устанавливает нам нужные куки. Но что это за “srp_” параметры и где наш PIN в запросах? Судя по всему, Сбербанк Онлайн использует Secure Remote Password protocol (SRP). Протокол реализует доказательство с нулевым разрешением (zero-knowledge proof), при котором сам PIN вообще не передается по каналу связи. На эту тему есть несложная статья на хабре, которая при этом наглядно объясняет принцип работы протокола. В ней, кстати, мы как раз можем увидеть, зачем нужны передаваемые в примерах параметры. Также Сбербанк Онлайн предлагает создать и passkey, чтобы использовать уже его при дальнейших входах при помощи WebAuthn. ➡️Тогда, естественно, никакого SRP уже нет, а есть запрос из authentication ceremony (скриншот 3). ➡️Далее опять же после запроса к /app/auth устанавливаются необходимые куки. Что здесь примечательно? Как видно из описанного процесса, данная последовательность запросов не то чтобы особо напоминает какой-либо OAuth flow. Соответственно, вполне логично, что подобный подход можно использовать и вне OAuth/OIDC. Кстати, в ходе экспериментов выявлено, что при использовании PWA с десктопа Сбербанк Онлайн, помимо passkey, запрашивал каждый раз еще и OTP из SMS, чего не происходило при тестировании с мобильного устройства. Детально разбираться уже не стал, подозреваю, что влияет передаваемый отпечаток (fingerprint). При использовании passkeys есть и нюанс. WebAuthn не позволяет ограничить, какой именно метод для user verification должен быть использован: это нельзя указать при начале церемонии, нельзя подобные данные получить и в authenticator data. Соответственно, со стороны приложения (relying party, RP в терминах WebAuthn) мы не сможем отличить, использовал ли пользователь для подтверждения своей identity на устройстве биометрию (например, отпечаток или распознавание лица) или же просто ввел системный PIN для разблокировки устройства (который у кого-то может быть выведен во что-то вроде “0000”). Если интересно почитать про user verification и user presence в WebAuthn, мне понравилась статья WebAuthn User Verification & User Presence for Passkeys. Вообще сама спецификация предусматривает ряд расширений (extensions). Так существует и User Verification Method Extension (uvm), которое как раз должно позволять RP получать значение использованного пользователем verification method. Например, здесь явно зарегистрированы такие значения как USER_VERIFY_FINGERPRINT или USER_VERIFY_PASSCODE. Однако, к сожалению, в Chrome такое не работает =( Не менее интересно и обоснование, почему это не поддерживается, взятое по ссылке выше:

Experiences such as "this website only works with my left index finger" and "I can't log into this website while wearing a mask" are not things that we wish to support. They damage the experience, and thus reputation, of modern authentication in general and encourage people to stick with passwords.

#iam_general

Как говорил профессор Фарнсворт из Футурамы: "Good news, everyone!" 📆 Уже 23 мая буду выступать на PHDays в Москве с докладом "Токены доступа и API Gateway: как обеспечить безопасность запросов" — [ссылка на доклад] (ребята из оргкомитета PHDays прислали и вот такую "красивую блогерскую картинку" (дословно!), так что ее тоже прикрепляем к посту) 📆 А всего через неделю после, 31 мая, я перемещаюсь в Новосибирск, где также выступлю с данной темой на 🎙 CodeFest 15 — [ссылка на доклад] В докладе поговорим про различные подходы использования API Gateway как части более общего API security-решения в контексте его работы с токенами доступа и подумаем, а есть ли лучший из них. Также обсудим, почему нужно ограничивать область действия access token и может ли API Gateway помочь и в данном вопросе. Так что, кто уже спланировал посетить данные конференции, приходите на доклад и просто пообщаться-познакомиться. А кто пока только планирует, вот вам еще один повод 😊 #announce #my_talk #api #iam_general

Опубликовал результаты исследования любопытного вектора атаки в виде статьи: https://habr.com/ru/articles/880544/ Также есть версия на английском языке на Medium. #my_publication

Упрощение повторной аутентификации в PWA (часть 1) Progressive Web Apps (PWA) - это веб-приложения, которые за счет использования дополнительных API позволяют улучшать UX и расширять функциональность стандартных возможностей веб-браузера. В случае мобильных платформ по сути такие PWA делаются выглядящими максимально приближенно к мобильным приложениям. Я вообще давно с надеждой смотрю на использование PWA в применимых для них случаях. Например, для реализации тонких клиентов, где не нужны сложные вычисления или работа с графикой. Также PWA многим могут быть знакомы и в связи с другими обстоятельствами: в последние годы они стали в том числе актуальны и в банковской отрасли РФ в связи с удалением приложений ряда банков из сторов. Долгое время их использование как полная альтернатива мобильным приложениям было под вопросом из-за особенностей политики Apple: Safari долгое время не поддерживал push-уведомления в PWA, что не давало разработчикам создавать полные аналоги "нативных" приложений и даже вынуждало городить разного рода костыли вроде отправки уведомлений в мессенджеры вместо этого для пользователей iOS. Однако в 2023 году и Apple поддержала наконец возможность отправки пушей. Правда, потом убив PWA для жителей EU =( С использованием PWA обычно хочется представить пользователю такой же опыт работы, как и в мобильном приложении. В том числе и в части аутентификации, ведь все знают, как пользователи это "любят". В мобильных приложениях широко распространён подход с упрощением повторных входов для пользователя: обычно приложение получает долгоживущий refresh token, сохраняемый в защищенное хранилище ОС, который используется далее. PWA такое повторить не могут. Нюанс в том, что PWA, при всем многообразии имеющихся API, доступа к защищённым хранилищам системы не имеют. Технически это все те же веб-приложения с теми же их особенностями и ограничениями. Поэтому очень интересно подумать, а какие подходы сейчас используются, чтобы и при повторных входах не и не заставлять пользователя использовать все факторы аутентификации, и не делать, например, access token (в случае OAuth) совсем долгоживущим. С одной стороны, раз это веб-приложения, то применяются известные практики для обновления access token, присущие им. Например: 1. Получение refresh token и хранение его в хранилищах клиентской части (таких как localStorage) 2. Получение refresh token и хранение его в HttpOnly-cookie (в том числе с другим path) 3. Обновление токенов через SSO Однако, порой может быть важно в каком-то виде выполнить и подтверждение identity пользователя на момент входа - вроде того, что в WebAuthn называют User Verification. Поэтому есть и принципиально другие подходы. В них при повторном входе мы все равно каждый раз выполняем аутентификацию пользователя, но уже по другой, альтернативной цепочке. Как правило, такая цепочка будет включать уже другие специфичные факторы, использование которых должно быть "проще" для пользователя. Здесь можно выделить отдельный PIN-код для устройства и использование passkeys (через WebAuthn) В следующей части посмотрим на такие подходы чуть подробнее уже на конкретном примере. #iam_general

Навигация по каналу ⛔️ Здесь описаны основные темы, освещаемые на канале, с использование хэштегов. #iam_general — материалы про Identity & Access Management #oauth — все, что касается OAuth и OIDC #security — про безопасность #api — проектирование, безопасность и интеграция API #jwt — про JWT и работу с ними #article — статьи из различных источников #paper — полноформатные работы, научные статьи #book — книги и обзоры книг #video — обзоры видео-материалов, докладов, выступлений #my_publication — мои опубликованные статьи #my_talk — мои выступления, доклады #announce — объявления о выступлениях, событиях Для просмотра всех постов, относящихся к данной теме, можно использовать поиск по нужному хэштегу. Список тегов будет дополняться по мере развития канала.

(продолжение предыдущего поста) Здесь я совсем не разделяю оптимизм автора. Считаю, что не все так просто и красиво. В выступлении приводятся аргументы (1️⃣), на них напишу ответы (1️⃣). 1️⃣: We can remove all OAuth 2.0 functionality from the frontend application 1️⃣: Не могу себе представить, как это может быть верно. Мы добавили обычный бэкенд, теперь у нас реализация authorization code flow с серверной частью. Однако клиентская часть все еще участвует: authorization request выполняется из браузера, а не с бэкенда. Authorization response возвращается так же в браузер. Да, выполнение token request переезжает (и хорошо), но это не является всей функциональностью, на мой взгляд. 1️⃣: Now we can reduce the attack surface from the full APIs that the token had access to to only the endpoints that the BFF exposes 1️⃣: Проблема здесь в некорректном сравнении. Автор сравнивает вызов API через шлюз в виде BFF с прямым вызовом конечного сервиса. Но в реальных системах конечные сервисы и не выставляются наружу голой жопой напрямую. Перед ними обычно используются какие-либо варианты реализации паттерна API Gateway, ну или другие прокси. Да и сам access token скорее всего ограничивается как минимум набором scopes. Подход не приносит фактической разницы: эндпоинты, с которыми клиентская часть работает, все так же доступны, но теперь через компонент, называемый здесь “BFF”. И доступ к ним все так же возможен. В определенном смысле здесь нет разницы, что нужно подать на вход снаружи: сам access token или некую абстракцию над ним. 1️⃣: The BFF observes all the API requests from a client, and can perform rate-limiting, anomaly detection, preventing data extraction and so on 1️⃣: Изначальная проблема была совсем не в наличии прямого доступа к API, вот где вижу подмену понятий. С чем здесь сравнивается использование описанного подхода? С приложением, у которого есть только клиентская часть, нет своего бэкенда, а сервисы со всеми эндпоитнами выставлены “наружу” напрямую? Я не говорю, что такая реализация невозможна и такого не бывает, однако для нее в целом нет особого смысла говорить о “безопасности”, здесь by design ее не особо заложено. Для приложений, где НФТ к надежности и ИБ хоть сколько-то важны, подобного мы не увидим в любом случае. А здесь же снова мы пытаемся показать решение всех проблем добавлением дополнительного уровня абстракции. Confidential client в целом-то можно и по-другому реализовать, не обязательно добавлять именно BFF как проксирующий шлюз. В итоге все подводится к тому, что подход с BFF значительно увеличивает безопасность. Только надо понять, в сравнении с чем. Автор поднял очень важные проблемы в первой части выступления, однако одно только добавление BFF как серверной части проксирующей запросы, не решает даже всего того скоупа упомянутых проблем. Делать токены доступными с клиентской части нехорошо, да. Но те же примеры с атакующим, способным инициировать новый OAuth flow, сами собой здесь не решатся. Атакующему не особо нужно получать сам access token для доступа к API. Ему предложили новый интерфейс с дополнительной абстракцией - да ради бога. Атакующий может получить authorization code, передать его своему серверу, где уже выполнить запрос с передачей его самому приложению. При серверном вызове при этом ничто не мешает получить значение session ID в ответе: это будет всего лишь заголовок Set-Cookie, какие бы атрибуты мы у него не написали. Кстати, скоро планирую опубликовать материал как раз про подобные атаки. Так что, как говорится, stay tuned. В заключении, описывая BFF как решение всех обозначенных проблем, автор добавляет, что:

That’s as good as it gets. We can’t do better

Считаю утверждение довольно спорным. По крайней мере, есть и альтернативы, и все же подходы к “do better”. Так точно ли BFF в данном случае - Best Friend Forever? #video #oauth

Видео The insecurity of OAuth 2.0 in frontends - Philippe de Ryck - NDC Security 2023 Еще одно выступление от Philippe De Ryck, про которого уже упоминал. Здесь автор уже говорит в целом про вопросы безопасности клиентских частей при использовании OAuth. В докладе отмечается популяризация приложений, которые состоят только из одной клиентской части. Клиентская часть веб-приложений пишется на JavaScript, поэтому логично упоминаются возможности исполнения вредоносного JS в браузере, что может быть вызвано: 🔵Скомпрометированной зависимостью или third-party скриптом 🔵 XSS Справедливо упоминается никуда не уходящая популярность наличия XSS, с отсылкой на статистику HackerOne, где XSS по-прежнему на первом месте. В OWASP top 10 2021 3 пункт Injection также включает в себя XSS (кстати, полезно напомнить, что первым является Broken Access Control) Автор обращает внимание, что при наличии токенов, доступных клиентской части в браузере, XSS несет дополнительный риск “извлечения токенов” (token exfiltration). Для снижения такого риска существующие практики рекомендуют меры вида снижения времени жизни токенов и ротации refresh-токенов вместе с защитой от переиспользования. Далее автор говорит про недостаточность таких мер, если токены все еще доступны с клиентской части. Собственно об этом он писал еще давно в своих статьях. Причину автор видит в недооцененности возможностей вредоносного JS, что довольно справедливо. Естественно, вредоносный JS выполняется в том же контексте и может все то же, что и легитимный код. Говорится про фокус именно на краже существующих токенов, однако, фокусируясь только на этой проблеме, мы не замечаем слона в комнате. Атакующему совершенно не обязательно пытаться украсть существующие токены приложения. Еще один эффективный вектор атаки заключается в получении атакующим новых, других токенов. Полностью согласен с этим высказыванием, здорово, что такой вопрос стал подниматься чаще. Приводится один из моих любимых примеров с т.н. “silent flow”, реализуемым через добавление iframe с URL authorization request с prompt=none и передачей authorization response родительскому окну через postMessage. Абсолютно логично, что в таком случае атакующий, имеющий возможность исполнения своего JS, может установить свой собственный EventListener на событие “message”, добавить невидимый пользователю iframe и, таким образом инициировав новый OAuth flow, похитить ответ, такой как authorization code с дальнейшим получением токенов на его основе. Еще раз хочу подчеркнуть, что пример абсолютно валидный. Детальнее про работу web message response mode тоже писал недавно, разбирая аутентификацию на портале разработчика Spotify. Также приводится правильная мысль о том, что использование proof-of-possession, в частности DPoP, не поможет в таком случае. Атакующий средствами того же JS может прилинковать токены к своим DPoP-секретам. Говорится о том, что люди стараются придумать различные меры защиты, не решающие root cause, в пример приводится использование service worker, имеющего возможность перехвата запросов. А затем автор демонстрирует недостатки такого подхода, заключающиеся в возможности дерегистрации service worker. Однако далее это все подводится к тому, что мы не можем защитить OAuth-flow, используя только браузер, упоминается, что если атакующий имеет подконтрольный URL на том же самом origin приложения, такие варианты атак все еще возможны. И в качестве решения здесь предлагается использование backend-компонента, который будет выполнять роль confidential client и реализовывать на себе всю работу с токенами. То что в контексте OAuth принято называть “Backend-for-Frontend (BFF)”. При этом на клиентскую часть возвращаются не сами токены, а некоторый session ID: то есть BFF создает отдельную сессию для пользователя. (продолжение см. ниже) #video #oauth

Кстати, между делом похвастаюсь, что давеча появился в Зале Славы багбаунти Яндекса. К концу квартала нахожусь на почетном 27 месте в общем списке 💪 Про интересную обнаруженную уязвимость, связанную с тематикой канала, тоже напишу, но попозже.

Identity Fabrics (часть 2) Продолжаем обсуждение темы из предыдущего поста. Понравилась концепция Time Phases. Здесь авторы говорят, что ранее выделяли только Deploy-Time (когда доступ и конфигурации identity определялись) и Run-Time (когда доступ применялся). Обновленная же модель вводит уже три различных фазы (с разбивкой одной из них): 1️⃣ Admin-Time 2️⃣ Real-Time (включает Session Initialization и Session Management) 3️⃣ Post-Event Time Детальнее см. изображение 1 (в порядке прикрепления к посту). Зачем это нужно? Далее при рассмотрении capabilities для каждой из них будет указана и соответствующая time phase (или несколько их). Подробно расписывается IAM Reference Architecture. Сама идея представлена в виде матрицы (см. изображение 2) Выделяют 4 домена: 1️⃣ Administration 2️⃣ Analytics & Risk 3️⃣ Authentication 4️⃣ Authorization 5 функциональных уровней: 1️⃣ Core 2️⃣ Privileged 3️⃣ Extended 4️⃣ Integrations 5️⃣ API И отдельный Foundation Layer, который поддерживает остальные и обеспечивает стабильность и функциональность IAM-инфраструктуры. А затем идет уже детальный разбор каждой из capabilities - самая объемная часть. Прочесть ее оказалось интересно, особенно про те аспекты, с которыми не довелось сталкиваться. Единственно, жаль что про уровень API здесь написали мало. И в конце указывается перечень рекомендаций для работы с данным фреймворками. Подытожим. Identity Fabric есть концепция (парадигма) и одноименный фреймворк, который нацелен на выстраивание архитектуры (экосистемы) IAM на уровне предприятия (enterprise). Он предлагает не смотреть на отдельные компоненты как на изолированные части, а говорит, что они являются частью целого в современных IT-ландшафтах. Привносит ли он что-то принципиальное новое? Не сказал бы. Однако предлагаемый комплексный подход в том числе на уровне стратегии кажется интересным. Был бы я корпоративным архитектором, кто знает, может и попробовал бы взглянуть на архитектуру предприятия и подобным образом. IAM Reference Architecture показалась достойной внимания. С одной стороны, если вы работали с функциями IAM в больших компаниях, многие поднимаемые вопросы будут вам уже знакомы. Но опять же общий взгляд может помочь избежать зашоренности взгляда порой. Где это все может быть применимо? Тут мои мысли в целом совпадают с тем, что пишут сами авторы. Тобишь использоваться это может при проектировании новых архитектур, аудита и анализа существующих и подходов к снаряду для создания стратегии трансформации и модернизации. А еще подумал, что такая информация из IAM Reference Architecture может быть полезна и для формирования роадмапа к развитию: например, можно взять для более глубокой проработки интересующие capabilities.

Identity Fabrics (часть 1) Пришла тут на почту реклама European Identity and Cloud Conference 2025, решил посмотреть, какие доклады там на повестке и заметил, что внимание уделяется концепции Identity Fabrics. Стало интересно попробовать разобраться, в чем же она заключается и есть ли в ней что-то новое, кроме красивых названий. Об этом, собственно, и поговорим. Как первоисточник, вводящий такое понятие, нашел статью ещё 2020 года Leveraging Identity Fabrics on Your Way Towards Cloud Based IAM (полный материал за пейволлом выложить здесь не могу, однако доступ можно получить в рамках бесплатного trial-периода). Тут нам говорится о том, что “традиционные IAM-решения не отвечают современным вызовам индустрии”, это и берется за проблематику. Изначально определение вводится следующее:

Identity Fabrics are a concept that serves as a viable foundation for enterprise architectures for Identity and Access Management (IAM) that serve the business demand. They provide the capabilities required for supporting the business use cases, based on a well-defined set of services that are built in a modern architecture. These services aim at providing access for everyone (and everything) to every service and system, in a controlled manner. As such they can serve as the conceptual foundation for sustainably transforming existing IAM infrastructures into a future-proof basic technology.

Также пишут:

It serves as the logical architecture that unites different services and delivers the capabilities required by the enterprise.

Составные части концепции показаны на изображении 1 (в порядке прикрепления к посту). А дальше приводится ряд довольно пространных шагов (без негатива), которые и должны привести читателя к светлому будущему. В общем, это некая вводная статья, которая по сути пока что “за все хорошее против всего плохого”. Поэтому за конкретикой обратился к как раз недавно опубликованному уже более состоятельному материалу: The 2025 Identity Fabric and IAM Reference Architecture (модель доступа аналогичная). В материал включены IAM Reference Architecture 2025, которая

provides a detailed and modular framework for designing, evolving, and integrating IAM capabilities. It offers a clear separation of functional layers and capabilities to ensure consistency, adaptability, and scalability across organizations of varying industries and sizes

И Identity Fabric 2025, который

serves as a strategic framework for building flexible, service-oriented IAM ecosystems. Unlike traditional IAM frameworks, the Identity Fabric focuses on creating a cohesive service delivery model that integrates identity management capabilities into broader enterprise strategies.

А вместе они должны являться основой, затрагивающей полный спектр IAM-вопросов для построения комплексных систем. Ключевые аспекты: 1️⃣ Building Block-Based Structure 2️⃣ Comprehensive Identity Coverage 3️⃣ Dynamic Authorization 4️⃣ Integrated Compliance 5️⃣ Support for Zero Trust 6️⃣ Strengthened Privileged Access Management 7️⃣ API and Interoperability Focus 8️⃣ Scalability Across Sectors Далее разбирается сама концепция Identity Fabrics через освещение основных ее компонентов: 1️⃣ Human and Non-Human Identities 2️⃣ Target Systems 3️⃣ Core of the Identity Fabric: Capabilities, Services, and Tools 4️⃣ Integration of Legacy Systems 5️⃣ Support for Digital Services and API Connectivity См. приложенное изображение 2. Говорится о том, что Identity Fabric - это не только технический фреймворк, но и стратегическая движущая сила (enabler). Интересна и связь с упомянутой IAM Reference Architecture. Пишут, что capabilities - и есть связующее звено между ними. Identity Fabric говорит о более верхнеуровневых вещах, в то время как IAM Reference Architecture предлагает уже более конкретные технические подходы и паттерны для каждой capability. Что должно помочь эффективной работе на разных уровнях и переходу от стратегических аспектов к архитектурным имплементациям. В следующей части поговорим про любопытную идею Time Phases, а также саму IAM Reference Architecture.

Статья «Account hijacking using “dirty dancing” in sign-in OAuth-flows» Сегодня хочу рассказать про статью Account hijacking using “dirty dancing” in sign-in OAuth-flows от исследователя Frans Rosén. Статья вышла еще в 2022 году, однако я с ней ознакомился только в начале данного года. Материал полезный, но мне показалось, что читается прям тяжело: возможно, из-за манеры повествования или из-за обилия тонкостей работы клиентских частей в браузере. Сначала для затравки в статье кратко рассматриваются основные response types и response modes в OAuth. Далее автор рассказывает, как начал искать уязвимости, связанные с postMessage, и даже применил интересную на тот момент технику: сделал расширение для Chrome для упрощения анализа. Разбираются тактики для прерывания OAuth flow, чтобы предотвратить использование authorization response (и атакующий мог его использовать сам). Или, как автор их называет, "non-happy paths". Среди них: 1. Передача невалидного значения state 2. Изменение response type/response mode для authorization request 3. Изменения регистра для redirect URI 4. Расширение пути (path) для значения redirect URI 5. Добавление query-параметров к значению redirect URI 6. Использование добавленных, но "забытых" redirect URI Кстати, отмечается полезная деталь для случаев с изменением redirect URI:

Please also note that using response_type=code this quirk is harder to exploit. In a proper OAuth-dance using code, in the last step to acquire the access token from the service provider, the redirect_uri must also be provided for validation to the service-provider. If the redirect_uri that was used in the dance is mismatching the value that the website sends to the provider, no access token will be issued. However, using any other response type, like token or id_token this last-step validation is not needed since the token was provided directly in the redirection.

В абзаце допущена небольшая ошибка: конечно, параметр redirect_uri передается т.н. identity provider (aka authorization server), а не "service-provider", как указано, но суть в целом отражена верно. Интересно это отметить, потому что в OAuth 2.1 этот параметр как раз исключен из token request с любопытным обоснованием. Далее автор пишет, что собрал набор сайтов с такими non-happy paths и стал их исследовать дальше. Производится категоризация URL-leaking gadgets - так автор называет различные методы утечки URL c параметрами authorization response. 1. postMessage-listeners, которые не проверяют origin и могут вернуть значение location.href назад в parent.window 2. Кейс Reddit: XSS на стороннем домене, поведение которого отражает URL с authorization response с основного домена 3. Third-party скрипты, которые исполняются на странице redirect URI и могут передать куда-либо значение URL с authorization response Также автор упоминает еще один теоретический гаджет, применения которого он не встретил: postMessage-listener, который проксирует полученные сообщения своему opener. В заключении автор приходит к выводу, что для защиты от подобных атак, страница, которая получает authorization response (redirect URI), не должна содержать third-party ресурсы или ссылки на сторонние сайты. Также говорится о подходе с ограничением использования только необходимых response types/response modes. При этом автор справедливо отмечает, что использование PKCE не защищает от таких атак. ____ В итоге для меня наиболее ценным стало описание способов для прерывания OAuth flow: я не думал в подобном ключе про такие тактики, а про некоторые из них и не знал совсем. Также импонирует итоговый посыл автора про ограничение использования third-party скриптов на страницах redirect URI и про лимиты в защите, предоставляемой PKCE.

ecom.teсh x keycloak community meetup 13 марта выступаю на митапе у ребят из ecom.tech, организованного совместно с русскоязычным keycloak-сообществом. Моя тема идет в самом начале и стартует сразу в 18:00. Поднимем вопрос о том, нужно ли использовать refresh-токены в веб-приложениях, и если нужно, то каким именно образом. Рассмотрим саму проблематику и выделим основную задачу, которую как раз обычно требуется решить. Обсудим, какие подходы здесь вообще применимы (спойлер: не только использование refresh-токенов), и поговорим про сами подобные токены: что это, зачем задумывались и как можно их использовать. А также сравним рассмотренные подходы с точки зрения информационной безопасности. Звучит, конечно, объемно и амбициозно для отведенного получаса, но постараемся охватить по-максимуму 😉 Когда: 13 марта, 18:00–20:15 МСК Формат: online Всего будет 3 темы: 🔵18:00-18:45 — ​​«Refresh token в веб-приложениях: быть или не быть?» (как раз моё выступление) 🔵18:45-19:30 — «Тернистый путь OAuth: от 2.0 к 2.1», Ирина Блажина, архитектор ИБ в Оператор Газпром ИД, co-owner Solutions of Security. Cпециализация на архитектуре для ИБ на базе решений FW, Proxy, NGFW, IDM, IAM, API-Gateway, IDS/IPS и др. 🔵19:30-20:15 — «Безопасность микросервисов: как защититься от уязвимостей аутентификации», Алексей Морозов, руководитель AppSec в ecom.teсh Так что приходите, надеюсь, будет полезно и интересно. Бесплатно и без смс, но предварительная регистрация все же нужна.

Кто хотел узнать, как устроена аутентификация на портале разработчика Spotify 🙋‍♂️? Ранее уже упоминали использование web message response mode, а developer.spotify.com как раз использует таковой. Поэтому сегодня в рубрике "а как у них" рассмотрим использование подобного response mode на реальном примере: https://telegra.ph/Autentifikaciya-na-developerspotifycom-01-22 А вообще полезно бывает обращать внимание на реализации в разных приложениях, пусть и с black box подходом: можно получить больше понимания, что происходит вокруг, какие практики и подходы применяются, подмечая как плюсы, так и минусы.

Web message response mode, и receiver origin vs redirect URI Итак, предыдущий пост мы закончили на мысли про различие redirect URI и receiver origin. Действительно, в случае web message response mode доступность authorization response ограничивается в рамках origin. Так при наличии возможности выполнения вредоносного JS на любой из страниц приложения с тем же origin атакующий действительно сможет получить отправляемые authorization server в postMessage-сообщении параметры authorization response. Однако насколько верно утверждение о том, что при использовании redirect-based flows атакующий сможет "дотянуться" до authorization response только при внедрении кода в саму страницу redirect URI? Все мы знаем, что выделенная страница redirect URI дарована нам для того, чтобы мы могли держать ее настолько пустой, насколько это возможно (даже аналитика может быть под вопросом). Это хорошо и правильно. Но достаточно ли этого, чтобы сказать, что authorization response теперь недоступен атакующему, "поселившемуся" в браузере у пользователя? Увы, нет. На самом деле, ограничение идет в рамках того же самого origin, а не какого-то конкретного пути. Основная суть в подобных атаках заключается в вызове тем или иным способом authorization request в браузере пользователя с последующим доступом к параметрам authorization response. Действуя в рамках одного origin, атакующий имеет и другие, помимо установки обработчика событий на получение событий "message", способы это сделать. Например, используя iframe или новое окно. Как известно, в современных браузерах существует защитный механизм Same-origin policy (SOP), который ограничивает взаимодействие страниц, имеющих различные origins. Таким образом, если мы, например, находясь на странице https://alice.com, откроем новое окно с origin https://bob.com, мы не будем иметь доступа к его содержимому, включая объект location. Здесь на помощь приходит лежащая в основе подобных OAuth flow redirect-based природа callback. Если атакующий в браузере пользователя создаст iframe или откроет новое окно c адресом authorization request, после выполнения редиректа на адрес redirect URI origin у страницы в окне/фрейме изменится на совпадающий с origin страницы родительского окна. Это и позволит атакующему получить доступ к объекту location для извлечения из него параметров authorization response, поскольку такое поведение допустимо в рамках SOP. Таким образом фактически различие есть только в том, что для случая с web message мы это осознаем более явно, а для redirect-based flows об этом как будто вообще не задумываемся. А суть в целом одна: модель безопасности в браузерах основана не на путях (paths), а на origins. Тем не менее я все равно настороженно отношусь к использованию postMessage. Это для меня является некоторой аналогией загрузки файлов, но из мира фронтенда: если можно обойтись без этого, то лучше так и сделать. Иначе слишком много мест, где можно обжечься.

Про различные response modes в OAuth Спецификация OAuth 2.0 Multiple Response Type Encoding Practices (она крохотная, не поленитесь посмотреть), кроме описания использования различных response types, вводит еще и понятие Response Mode:

The Response Mode determines how the Authorization Server returns result parameters from the Authorization Endpoint. Non-default modes are specified using the response_mode request parameter. If response_mode is not present in a request, the default Response Mode mechanism specified by the Response Type is used.

Сам документ изначально регистрирует всего два значения для параметра response_mode: - query; - fragment. Однако тут же отмечается, что

See OAuth 2.0 Form Post Response Mode [OAuth.Post] for an example of a specification that defines an additional Response Mode. Note that it is expected that additional Response Modes may be defined by other specifications in the future, including possibly ones utilizing the HTML5 postMessage API and Cross Origin Resource Sharing (CORS).

И действительно, в дополнение к вышеобозначенным, мы часто встречаем и следующие: - form_post; - web_message. Form post response mode представляет собой ответ в виде HTML-страницы с формой, которая при загрузке страницы через User Agent автоматически отправляет параметры authorization response на адрес redirect URI (<form method="post" action="https://site.com/callback">). Таким образом данные передаются через POST-запрос к обозначенному эндпоинту. Подход далеко не новый: аналогичное мы могли наблюдать еще со времен SAML POST Binding. Web message response mode предполагает отправку параметров authorization response через postMessage API. Здесь используется открытие в новом окне (popup) или же внутри iframe URL с адресом authorization request. В ответ authorization server так же возвращает HTML-страницу, которая средствами JS отправляет параметры authorization response родительскому окну. Вообще данный response mode не то чтобы был особо специфицирован, однако это не мешает ему находить применение в реальных имплементациях. Про не особо специфицирован: можно найти только два уже протухших драфта, откровенно говоря, в зачаточном состоянии: 🔵OAuth 2.0 Web Message Response Mode Здесь могу выделить довольно странную схему "Relay Mode". Базово стоит полагать, что как минимум Unauthenticated Window будет иметь другой origin, поскольку это страница, принадлежащая authorization server. С таким допущением попробовал сделать PoC, чтобы проверить реализацию, однако шаг 7

Unauthenticated window obtains the window object of the Message Target Window via the MessageEvent object in the Relay Response and send Authorization Response as a Web Message.

выглядит нереализуемым в современных браузерах из-за Same-Origin Policy, а также из-за невозможности передать в сообщении ссылку на объект window без сериализации, как это предлагается. Таким образом не вижу возможности реализовать отправку сообщений между двумя подобными фреймами. Однако допускаю и что моих знаний JS не хватило, чтобы понять предложенную схему. 🔵OAuth 2.0 Web Message Response Mode for Popup- and Iframe-based Authorization Flows Соавтор драфта, кстати, является автором понравившейся мне магистерской диссертации, про которую уже писал. Выделить могу интересную цитату в Security Considerations:

In flows using the web message response mode, the confidentiality of the authorization response is scoped to the postMessage's receiver origin that does not contain a path. Thus, cross-site scripting (XSS) vulnerabilities on any path within the web application's origin will leak the authorization response to the attacker.

Про это поговорим чуть подробнее в дальнейших постах. Давно проверяли, какие response modes поддерживает ваш authorization server? Загляните, например, в /.well-known/openid-configuration, обычно это отражается и там.

Top 10 web hacking techniques of 2024 от PortSwigger (часть 2) Не менее интересно также обратиться к полному списку номинантов и указать статьи, не вошедшие в топ. 4️⃣ POST to XSS: Leveraging Pseudo Protocols to Gain JavaScript Evaluation in SSO Flows Материал про то, как возможность указания в качестве значения redirect URI URI-схем (или же псевдопротоколов) а-ля javascript: в сочетании с form post response mode может позволить получить XSS уже на стороне самого authorization server (что, конечно, открывает широкие горизонты перед атакующим). 5️⃣ Zoom Session Takeover - Cookie Tossing Payloads, OAuth Dirty Dancing, Browser Permissions Hijacking, and WAF abuse Last but not least, мне кажется, материал незаслуженно обделили. Опубликован, кстати, в том же блоге, что и упомянутая статья про Web Cache Deception в chat.openai[.]com. ✏️Авторы нашли интересную cookie-based XSS через отражение (reflection) значения куки с CSP nonce, причём по их словам отражение было на всех страницах всех поддоменов zoom.us. Однако особенность такой XSS в том, что нужно ещё найти подходящий начальный вектор, например, cache poisoning, которое однако было неприменимо в данном случае. ✏️Здесь авторы пришли к использованию cookie tossing, чтобы "пробросить" установленную на поддомене куку на основной домен, что обеспечило им наличие XSS на нем. Большие компании вроде Zoom обычно имеют множество поддоменов, аудит которых не всегда может тщательно вестись. Многие из таких поддоменов обычно сами по себе не представляют ценности, и XSS на них могут показаться не сильно полезными. Однако, это не всегда так. В статье авторы нашли POST-based XSS на одном из поддоменов, и использовали ее для реализации XSS уже на домене основном. ✏️Далее, уже имея таким образом возможность выполнения JS на основном домене, выполняется кража параметров authorization response со страницы redirect URI и получение session ID на их основе. ✏️Отдельно хочу отметить очень интересную часть про использование того факта, что Zoom есть платформа для аудио- и видео-встреч, а следовательно у пользователей, использовавших веб-версию zoom, уже будут выданы в браузере разрешения на использование камеры и микрофона. Cookie-based натура у XSS в данном случае обеспечила автором постоянство (persistence) в выполнении внедренного JS, что они использовали для демонстрации возможности захвата аудио- и видео-потока на устройстве пользователя и отправки его на сервер атакующего. ✏️Также продемонстрирована возможность – опять же, за счет использования кук – обернуть использование WAF против самих Zoom: установить пользователю куку с пейлоадом, на который реагирует WAF, что по факту "забанит" доступ пользователя ко всему сайту или – это круче всего – к выборочным страницам за счет использования атрибута path у куки. Вот это правда вау, как по мне, читать было очень интересно. Глядя на все это, можно заняться любимым делом: попыткой сделать выводы на основе нерепрезентативных предвзятых подборок! Что примечательного могу отметить: - Все еще видим неплохие материалы по атакам в контексте OAuth и аутентификации, значит и работа над мерами защиты не перестает быть актуальной - Немало материалов так или иначе упоминают "OAuth Dirty Dancing", что отсылается к известной статье от Frans Rosén (про которую, кстати, скоро поговорим на канале) - XSS по-прежнему "still alive & kickin'" - Неожиданно неоднократно упоминают cookie tossing В целом отмечаю интересное направление, показывающее актуальность атак с кражей authorization response и дальнейшим его использованием для получения account takeover - рассчитываю, что в течение весны сможем более подробно поговорить про эту тему и проверить, точно ли предлагаемые обычно меры защиты так эффективны. Естественно, читать такие материалы полезно не только если вы обычно представляете атакующую сторону, но и если вашей задачей так или иначе является проектирование систем. Чтобы понять, как и от чего стоит (или не стоит) защищаться, нужно понимать и сами принципы, стоящие за атаками и уязвимостями.

Top 10 web hacking techniques of 2024 от PortSwigger (часть 1) Сбылась моя мечта, хоть раз опубликую здесь что-то актуальное и свежее. Буквально вот только что был опубликован уже ставший ежегодным топ лучших публикаций и ресчерчей в области ИБ за 2024 год по версии PortSwigger. Дата оглашения была известна заранее, поэтому я успел подготовиться и прочитать заранее интересующие статьи 😈. А здесь хочу выделить интересные с точки зрения тематики канала материалы. 1️⃣ Hijacking OAUTH flows via Cookie Tossing - 10 место Большая часть статьи - это, к сожалению, вода. Однако здесь меня сильно повеселила фраза "Revisiting GitPod". Когда я занимался исследованием вопроса аутентификации для WebSocket, находил материал от тех же snyk.io про интересный кейс с раскруткой Cross-Site WebSocket Hijacking (CSWH) до RCE на примере GitPod. Там как раз был нюанс в использовании поддоменов .gitpod.io для обхода SameSite. Показалось забавным, что авторы снова вернулись к бедному GitPod и снова что-то у них нашли, причем опять за счет поддоменов. 2️⃣ ChatGPT Account Takeover - Wildcard Web Cache Deception - 9 место Читающие канал более года обратят внимание, что этот материал уже освещался здесь ранее - как раз во время своей изначальной публикации. 3️⃣ OAuth Non-Happy Path to ATO - 8 место Предлагается довольно любопытный подход к краже authorization response для случая, когда страница с redirect URI в случае "неуспеха" отражает значение из переданного заголовка запроса Referer в заголовке ответа Location, что способствует редиректу. Автор использует прокидывание заголовка Referer через цепочку редиректов, а также особенность работы браузеров, заключающуюся в распространении части URI fragment при выполнении редиректа (в отличие от тех же query-параметров). На этом в самом топе все, но в следующем посте посмотрим и на другие, на мой взгляд, достойные внимания публикации.