Есть еще интересный нюанс. В п. 7.1 RFC 9636 мы видим предполагаемую возможность пользователю в процессе согласия указать или уточнить какую-то информацию, изначально не входившую в authorization_details. Например, выбрать конкретный счет, к которому хотим предоставить доступ, из списка. Учитывая, что экран согласия обычно находится в ведении AS, появляется вопрос: откуда у AS возьмется информация о тех счетах, которые имеет пользователь? Неужто AS должен сам это знать?
Не найдя однозначного ответа, решил обсудить вопрос с авторами самого RFC.

🟡Сам ответ, "как" AS получит какие-либо данные для отображения пользователю лежит за рамками данного RFC, и какого-либо референтного подхода тут, увы, не предполагается
🟡Задумка меня пока смущает. Не вижу до конца, как "красиво" реализовать пусть тот же самый пример с выбором счета, к которому надо предоставить доступ. То есть придется либо запрашивать данные по ним от лица самого AS, либо, допустим, асинхронно обогащать данные по пользователям, хранящиеся на стороне AS, краткими данными по списку их счетов (пусть маскированными представлениями). Но вот перспектива примешивать в AS какие-то бизнес-данные пока что-то не радует
🟡Зато мне любезно предоставили один из примеров, как это реализовано. Надеюсь, будет вполне этично поделиться здесь:

In Authlete we’ve got three components working together — an IdP (the AS), an Authlete Server (the RS), and the console (the client).

When the client goes and talks to the AS, the client doesn’t know which set of services the user has access to, so it can’t ask for a detailed list of rights from the AS since it has no idea who the user is let alone what that user can access. The client at this point doesn’t even know where the RS’s are — since in our environment, each installation of the RS is managed separately for access rights.

So the client just asks for a basic scope, "authlete", that just tells the RS "anything on the authlete APIs that this user can do", which is appropriate for a client to be able to ask for.

The AS knows which paid and free accounts the user is attached to, and therefore which services on which Authlete Server installations the user has access to. So when the AS makes the token, it puts that information into the token’s metadata (we use introspection in our case). The client in our case doesn’t read the RAR data back itself, it learns of which RS’s that it can call through an API call back to the AS. The RAR object captures which services on which RS’s the client can do which actions to.

When the token gets used by the client to call the RS, the RS doesn’t know anything about the user or accounts that went into making the token, but it doesn’t have to. The RAR object on the token simply lists out which services the client can access and for what purposes, so it’s a really easy and simple check. And that same token can be targeted to multiple RS’s, like if the user’s got access to a Dev and Prod environment on different servers.

This lets us keep our user data in one place instead of spreading it out across multiple RS’s. And the RS’s don’t have to do any secondary checks against a backend system to map a user ID to a service ID.

Еще говорят, на грядущем OAuth Security Workshop 2024 как раз расскажут подробнее про проект из описанного примера. Но, увы, мероприятие нацелено на оффлайн и проходит в Риме =(
Возможно, далее появятся и в онлайне какие-либо материалы с интересными примерами.

#oauth

Видео "JWT vs. mTLS for service-to-service authentication" от solo.io

Интересное видео про различные способы межсервисной аутентификации. Обозначают основную проблематику: "Как сервису B достоверно определить, что к нему действительно обращается сервис A?" и дальше идут от этого.
Ребята рассматривают 3 подхода:
🔵OAuth 2.0 access token в виде JWT
🔵самоподписанный JWT на уровне сервиса
🔵mTLS с использованием SPIFFE

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

Поднимается важность безопасности при разработке, несмотря на частое желание "to stay away from it". При этом все равно отмечают, что атака может быть проведена не только с использованием какой-то супер-крутой 0-day уязвимости, но и как результат эксплуатации цепочки, состоящей из того, что по отдельности может казаться мелочами ("Death by a Thousand Cuts").

Упоминается и использование API GW как централизованного места, на которое можно "сгрузить" часть security-фичей, чем обеспечив более гарантированное и консистентное их применение для всех сервисов. Но логично подмечают, что такой подход идет преимущественно для north-south взаимодействий, и особо не применяется для east-west, особенно если API GW находится где-то снаружи или далеко от окружения, где развернуты сервисы.

Вообще выделяется важность токенов, говорят о том, что это те же секреты, дающие возможность доступа, и нужно думать об ограничении и их времени жизни, и области применения.
Для кейса с access token очень правильно поднимают вопрос важности audience для токенов, который тоже порой хотелось бы слышать почаще. Что, мол, не все вообще используют audience, а если использовать "по уму", тобишь иметь различные токены для различных audience, то получаем необходимость сервису иметь кучу токенов, которые еще и надо все время обновлять.

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

Отмечают, что mTLS при корректной реализации позволяет закрыть не только задачи шифрования трафика, но и как раз аутентификации между сервисами. При этом акцент делают на реализации с применением service mesh, поскольку в таком случае на mesh, опять же, возможно "сгрузить" ряд универсальных для всех сервисов фичей, в том числе по работе с сертификатами. По словам авторов такой подход дает больше уверенности платформенной команде, что функциональность, касающаяся безопасности, реализована у всех и одинаково.

Отдельно обращу внимание, что кратко упоминается любопытный поинт о том, что в концепции SPIFFE вообще-то SPIFFE Verifiable Identity Document (SVID), который является сущностью, подтверждающей Identity вызывающей стороны, может быть не только в виде X.509 сертификата, но и в виде JWT. И теоретически это может работать, но реализаций таких авторы пока не встречали.
Отличие, согласно видео, здесь в том, что в случае с сертификатом сам "секрет" никуда не отправляется и не покидает пределов самого сервиса, который его получил. Используется только публичный ключ. А вот JWT, который сам по себе уже чувствительный, нам бы уже пришлось отправлять, как говорится, "по сети".

В общем видео показалось интересным и полезным, ребята говорят толковые вещи.

#video #iam_general

Видео доклада "Supercharging OAuth 2.0 Security" от Philippe De Ryck с DevFest 2024 в Копенгагене.

Не так давно на канале NDC Conferences (очень классный канал, советую) была опубликована запись данного выступления. Вообще Philippe De Ryck, насколько я встречал его работы, специализируется больше на безопасности клиентских частей веб-приложений в контексте вопросов аутентификации. Это можно увидеть из его блога или соавторства в драфте OAuth 2.0 for Browser-Based Applications.

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

➡️Так упоминается RFC 8707 Resource Indicators for OAuth 2.0 для ограничения области действия access token, отмечаются особенности работы подхода с точки зрения получения новых токенов на стороне Cilent.

➡️Поднимается вопрос обеспечения безопасности для Authorization request, а особенно обеспечения его целостности (integrity) и защиты от манипуляций (tampering). В этом контексте вспоминаем про JWT-Secured Authorization Request (JAR) и Pushed Authorization Requests (PAR).
Для JAR параметры Authorization request оборачиваются в специальный JWT, подписанный на стороне Client. Соответственно в issuer фигурирует client_id, а audience является уже сам Authorization server. При выполнении самого Authorization request вместо использования query-параметров в plain-text передается как раз созданный JWT.
В случае PAR в Authorization request параметры не передаются вовсе, а передается только специальный идентификатор, соответствующий предварительно созданному набору параметров Authorization request.

➡️Говорит автор также и про извечные проблемы bearer-токенов и не менее извечное движение к sender-constrained токенам доступа.
Кратко рассматривается использование основных proof-of-possession механизмов: mTLS и DPoP, справедливо отмечая, что реализация данных подходов может быть не так проста и не всегда оправдана.

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

#video #oauth

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-параметров).

На этом в самом топе все, но в следующем посте посмотрим и на другие, на мой взгляд, достойные внимания публикации.

#security #article

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 - рассчитываю, что в течение весны сможем более подробно поговорить про эту тему и проверить, точно ли предлагаемые обычно меры защиты так эффективны.

Естественно, читать такие материалы полезно не только если вы обычно представляете атакующую сторону, но и если вашей задачей так или иначе является проектирование систем. Чтобы понять, как и от чего стоит (или не стоит) защищаться, нужно понимать и сами принципы, стоящие за атаками и уязвимостями.

#security #article

Про различные 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, обычно это отражается и там.

#oauth