- Вопрос или проблема
- Связывание кода авторизации с ключом DPoP на основе PKCE
- Общее замечание о DPoP и PKCE
- Ответ или решение
- Применение связывания кода авторизации с DPoP-ключом при использовании PKCE для конфиденциальных клиентов
- Зачем нужно связывание кода авторизации с DPoP-ключом?
- Проблемы с безопасностью и XSS
- Рекомендации FAPI 2.0
- Заключение
Вопрос или проблема
Этот стандарт определяет механизм DPoP для криптографического связывания токенов доступа. Также упоминается связывание с кодом авторизации.
Но вы видите в этом какой-то смысл? Да, это явно способ предотвратить атаки инъекции кодов авторизации, но PKCE выполняет то же самое и является более легковесным.
Более того, конфиденциальный клиент ДОЛЖЕН быть аутентифицирован на конечных точках Pushed Authorization и Token, так что не имеет смысла что-то вроде “связывания с владельцем”, если используется PKCE.
Но Профиль безопасности FAPI2.0 утверждает, что авторизационный сервер:
если использует DPoP, должен поддерживать “Связывание кода авторизации с ключом DPoP” (как требуется в разделе 10.1 [I-D.ietf-oauth-dpop]).
Мы знаем, что FAPI2.0 обрабатывает только конфиденциальные клиенты. Почему они требуют поддержки связывания кода авторизации? Есть ли какие-либо преимущества у этого подхода?
Связывание кода авторизации с ключом DPoP на основе PKCE
Сфокусируемся на коде авторизации, предполагая, что реализованы как DPoP, так и PKCE. Насколько я могу судить, это может добавить некоторую ценность, хотя, вероятно, не очень высокую и в довольно специфических обстоятельствах.
Спецификация DPoP говорит следующее:
Если авторизационный сервер не (или не может) строго применять ограничение на одноразовое использование кодов авторизации, и злоумышленник может получить доступ к коду авторизации (и если используется PKCE, то к коду проверки), злоумышленник может создать поддельный запрос токена, связывая полученный токен с контролируемым злоумышленником ключом. Например, использовав XSS, злоумышленники могут получить доступ к коду авторизации и параметрам PKCE. Использование параметра dpop_jkt предотвращает такую атаку.
Если честно, ссылка на XSS может быть не самым лучшим примером. Если злоумышленник добился успеха с XSS и получил доступ к коду авторизации и проверяющему коду PKCE, то весьма вероятно, что он также может получить доступ к закрытому ключу DPoP или, по крайней мере, выполнять операции подписи с его помощью (если он хранится в недоступном для экстракции хранилище). Они даже точно это говорят в разделе о ненадежном коде в контексте клиента.
Я думаю, более разумные примеры – это доступ к HTTP-логам в случае, если PKCE использует code_challenge_method = plain.
Еще один интересный момент в разделе 10:
Использование параметра запроса авторизации dpop_jkt является НЕОБЯЗАТЕЛЬНЫМ. Обратите внимание, что параметр запроса авторизации dpop_jkt ТАКЖЕ может использоваться в сочетании с ключом доказательства для обмена кодами (PKCE) [RFC7636], что рекомендуется [SECURITY-TOPICS] как контрмеры к инъекции кода авторизации. Параметр запроса авторизации dpop_jkt предоставляет аналогичные меры защиты только при использовании уникального ключа DPoP для каждого запроса авторизации.
Что предполагает, что ключи DPoP предполагаются, чтобы повторно использоваться владельцем клиента в течение длительного времени, в то время как проверяющий код PKCE генерируется заново каждый раз.
Общее замечание о DPoP и PKCE
Эти два метода не взаимозаменяемы. Их основные цели совершенно разные.
- Ключ доказательства для обмена кодами публичными клиентами OAuth (PKCE) – связывает код авторизации с конкретным отправителем. введите описание ссылки здесь
- Демонстрация доказательства владения (DPoP) – предназначена для ограничения отправителя токенов OAuth 2.0, т.е. токенов доступа и обновления. Этот механизм позволяет обнаруживать атаки воспроизведения с помощью токенов доступа и обновления. Аннотация RFC 9449
Существуют некоторые пересечения, но в целом они, похоже, дополняют друг друга. Настоятельно рекомендую этот ресурс для целостного взгляда: Лучшие текущие практики безопасности OAuth 2.0
Ответ или решение
Применение связывания кода авторизации с DPoP-ключом при использовании PKCE для конфиденциальных клиентов
Вопрос о целесообразности использования связывания кода авторизации с DPoP-ключом (Demonstrating Proof of Possession) в контексте конфиденциального клиента, который также использует PKCE (Proof Key for Code Exchange), представляет собой интересную тему, которую стоит проанализировать глубже.
Зачем нужно связывание кода авторизации с DPoP-ключом?
Во-первых, связывание кода авторизации с DPoP-ключом действительно может предотвратить атаки с инъекцией кода авторизации, что является важным аспектом безопасности OAuth 2.0. Однако, как вы правильно заметили, PKCE уже обеспечивает защиту от данного типа атак и делает это более легковесным способом.
Следует учитывать, что DPoP и PKCE служат для решения различных задач. PKCE создает связь между кодом авторизации и конкретным отправителем (клиентом), а DPoP действует как механизм, который ограничивает возможность использования токенов доступа и обновления, защищая от повторных атак.
Проблемы с безопасностью и XSS
Отдельно стоит отметить, что, несмотря на то, что спецификация DPoP упоминает про возможные атаки через XSS, эта угроза может быть и не самой значимой. Действительно, если злоумышленник получает доступ к коду авторизации и параметрам PKCE, то он, вероятно, также сможет получить доступ к приватному ключу DPoP или использовать память клиента для исполнения операций подписи. Это ведет к выводу, что успешная атака XSS может не оставить недоступных для злоумышленника ресурсов.
Однако, важно учитывать сценарии, в которых код авторизации может попасть в логи HTTP — это может происходить в случае, если PKCE использует метод code_challenge_method=plain. В этом случае связывание кода авторизации с DPoP-ключом может добавить дополнительный уровень защиты.
Рекомендации FAPI 2.0
Важно отметить, что спецификация FAPI 2.0, требуя поддержки механизма "Authorization Code Binding to DPoP Key", учитывает возможность более строгого контроля безопасности. Эта поддержка может рассматриваться как дополнительная мера предосторожности или улучшение общего уровня безопасности системы, особенно в условиях высокой угрозы.
Заключение
В общем, можно заключить, что связывание кода авторизации с DPoP-ключом в контексте использования PKCE не является необходимым шагом для конфиденциальных клиентов, особенно если они правильно реализуют текущие механизмы безопасности. Однако в специфических условиях, когда существуют дополнительные риски безопасности, такая мера может добавить слой защиты.
Важно понимать, что DPoP и PKCE — это взаимодополняющие механизмы, которые решают разные проблемы. PKCE сосредоточен на защите кода авторизации, тогда как DPoP стремится гарантировать, что токены доступа не могут быть использованы повторно злоумышленниками. Это сочетание может предложить более безопасное решение для конфиденциальных клиентов, стремящихся минимизировать риски, связанные с авторизацией и доступом.