Каковы различные возможные способы взлома злоумышленника access_token и/или refresh_token?

Question

Существует много дискуссий практически на всех форумах о безопасности веб-приложений (не учитывая мобильные приложения), специально используя oauth2 и jwt. Все ставят свои комментарии/ответы на этот вопрос, blah..blah..blah о жетонах безопасности (предполагая, что почти весь ценный веб-сайт, возможно, стал апатридом к этому концу конца 2016 года). Серьезно, я не знаю, если это так просто, я нашел, что все пишут свои ответы против воображаемого злоумышленника, как будто это настолько расслабленно и легко нападающим, чтобы украсть клиентское веб-приложение пользователя access_token и refresh_token. Каковы различные возможные способы, которыми злоумышленник может нанести ущерб вашему веб-приложению, выпущенному access_token и refresh_token на стороне клиента? Этот компромисс также зависит от пользователя, использующего веб-приложение? Как легко злоумышленник может подслушивать любые сообщения между клиентом и сервером авторизации? Любые примеры открытого кода, если кто-то хочет продемонстрировать, будут высоко оценены. Стремясь найти ответы на вопросы, а не утомительные дискуссии о безопасности веб-приложений. Я хочу извиниться, если это вопрос Кворы.

Answer 1

Есть много обоснованных вопросов о безопасности OAuth2 в целом.

Несколько лет назад, когда OAuth2 был всего лишь черновиком, один из основных участников этой спецификации написал an interesting blog post по этой теме. И он прав: этот рамочный протокол предоставляет много возможностей для простого олицетворения клиента и получения доступа к пользовательским ресурсам или отправки действительных запросов, включая запросы администратора.

Основная причина в том, что RFC6749 четко указывает, что он полагается на соединение TLS. Атаки редко зависят от пользователя, если маркер доступа не экспортируется. Человек в среднем, вредоносное мобильное приложение, обратное проектирование, грубая сила ... - это некоторые из доступных способов получить токен доступа. Трудно получить исчерпывающий список всех типов атак.

Однако, поскольку это протокол рамок, ничто не мешает реализовать дополнительные функции безопасности. Именно поэтому the IETF OAuth2 Working Group работает над некоторыми очень интересными усовершенствованиями для защиты всех заинтересованных сторон (клиентов, серверов авторизации, серверов ресурсов) и связи между ними.

Я рекомендую вам прочитать следующие РЛК или проекты:

• RFC6819: дает дополнительные соображения безопасности для OAuth.
• RFC7800, POP Key Distribution и POP Architecture, которые пытаются заменить abandonned MAC access tokens
• RFC7009 для маркера отзыва
• RFC7521, RFC7521 и RFC7521, который реализует новые методы аутентификации клиента на основе JWT или SAML2 утверждений
• RFC7636: Proof Ключ для кода Exchange для предотвращения появления вредоносного мобильного приложения, а затем токена доступа

Кроме того, вас также может заинтересовать token binding draft, который является (из моего POV) основным улучшением, поскольку он связывает токены с TLS-соединением. Другими словами, даже токен доступа скомпрометирован (или преднамеренно экспортирован), он не может использоваться, поскольку соединение TLS будет другим.

Другие проекты, связанные с безопасностью OAuth2 доступны на the IETF OAuth2 Working Group странице (см signed requests, closing redirectors, X.509 Client authentication ...).