секрет клиента в OAuth 2.0

95

Чтобы использовать google drive api, мне нужно поиграть с аутентификацией с помощью OAuth2.0. И у меня есть несколько вопросов по этому поводу.

  1. Идентификатор клиента и секрет клиента используются для определения моего приложения. Но они должны быть жестко запрограммированы, если это клиентское приложение. Итак, каждый может декомпилировать мое приложение и извлечь их из исходного кода. Означает ли это, что плохое приложение может притвориться хорошим, используя идентификатор и секрет клиента хорошего приложения? Таким образом, пользователь будет показывать экран, на котором запрашивается разрешение на хорошее приложение, даже если оно действительно запрашивается плохим приложением? Если да, что мне делать? Или мне вообще не стоит об этом беспокоиться?

  2. В мобильном приложении мы можем встроить веб-просмотр в наше приложение. А поле пароля в веб-просмотре легко извлечь, потому что приложение, запрашивающее разрешение, на самом деле является «браузером». Итак, OAuth в мобильном приложении не имеет того преимущества, что клиентское приложение не имеет доступа к учетным данным пользователя поставщика услуг?

security  oauth  google-api  oauth-2.0 
— нести
источник
2
Также я думаю, что у людей обычно возникают подозрения, когда приложение запрашивает у них их учетные данные Facebook, Twitter, Dropbox или другие. Я сомневаюсь, что многие обычные люди читают спецификацию OAuth и говорят: «Теперь я в безопасности», но вместо этого руководствуйтесь здравым смыслом и, как правило, не используют приложения, которым они не доверяют.
— Игорь Кордаш
Действительно отличный вопрос определенно должен набрать больше очков
— Шраван
вы можете просто загрузить ClientId и секрет со своего сервера и сохранить их в цепочке для ключей при первом успешном входе в систему, вот и все
— Шраван
@Sharvan Я могу ошибаться, но я думаю, что брелки уязвимы на рутированных телефонах, поэтому секрет вашего клиента может быть обнародован.
— chichilatte

Ответы:

16

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

  1. Да, для этого есть реальная возможность, и на основе этого были некоторые эксплойты. Предлагается не хранить приложение в секрете в своем приложении, в спецификации даже есть часть, что распределенные приложения не должны использовать этот токен. Теперь вы можете спросить, но XYZ требует этого для работы. В этом случае они не реализуют спецификацию должным образом, и вам не следует A использовать эту службу (маловероятно) или B пытаться защитить токен с помощью некоторых методов обфускации, чтобы затруднить поиск или использование вашего сервера в качестве прокси.

    Например, были некоторые ошибки в библиотеке Facebook для Android, где происходила утечка токенов в журналы, вы можете узнать больше об этом здесь http://attack-secure.com/all-your-facebook-access-tokens-are-belong - нам и здесь https://www.youtube.com/watch?v=twyL7Uxe6sk . В общем, будьте особенно осторожны при использовании сторонних библиотек (на самом деле здравый смысл, но если захват токенов - ваша большая проблема, добавьте еще одну дополнительную осторожность).

  2. Я довольно давно разглагольствовал по поводу пункта 2. Я даже применил некоторые обходные пути в своих приложениях, чтобы изменить страницы согласия (например, изменив масштаб и дизайн в соответствии с приложением), но ничто не мешало мне читать значения из полей внутри веб-представления с именем пользователя и паролем. Поэтому я полностью согласен с вашим вторым пунктом и считаю это большой «ошибкой» в спецификации OAuth. То, что «приложение не получает доступ к учетным данным пользователей» в спецификации, является просто мечтой и дает пользователям ложное чувство безопасности ... Также я предполагаю, что у людей обычно возникают подозрения, когда приложение запрашивает их учетные данные Facebook, Twitter, Dropbox или другие. Я сомневаюсь, что многие обычные люди читают спецификацию OAuth и говорят: «Теперь я в безопасности», но вместо этого руководствуйтесь здравым смыслом и, как правило, не используют приложения, которым они не доверяют.

— Игорь Кордаш
источник
3
Ваш идентификатор клиента и секрет клиента не будут защищены только потому, что вы разместите их в туннеле SSL. Да, они более защищены от атак человека посередине. Если пользователь передает ваш HTTP-вызов через прокси, он может принять плохой сертификат и просмотреть все, что вы публикуете. Кстати, это самый простой способ украсть чей-то клиентский секрет на мобильных устройствах.
— EpicThreeDev 08
5
Я ценю ваш комментарий, но никак не могу связать его с моим ответом ... Не могли бы вы пояснить, почему вы прокомментировали мой ответ, потому что я прямо заявил, что секрет клиента не должен использоваться в распределенных приложениях, а другой момент заключался в том, что существуют обходные пути для получения учетных данных пользователя в приложениях даже при использовании OAuth, поэтому пользователи должны доверять поставщику приложения, а не OAuth.
— Игорь Кордаш 09
Также я не понимаю, что вы имеете в виду, говоря «Если пользователь проксирует ваш HTTP-вызов», да, пользователи получают доступ к данным, которые они отправили с помощью HTTP, и они могут свободно выполнять прокси-вызовы, как им нравится. Как я понял, вы предлагаете это как довольно хорошую альтернативу разборке apk для получения секрета, но опять же, вам не следует отправлять секрет приложения в первую очередь.
— Игорь Кордаш 09
Итак, для пункта 1) плохое приложение должно иметь доступ к той же системе и получать токен доступа / обновления с того же устройства?
— Гаут,
Непонятно, что вы считаете «той же системой» в этом контексте. Приложение создает веб-просмотр, в котором отображается страница подтверждения, и может получить доступ ко всем данным в этом представлении (включая файлы cookie или параметры URL-адреса, на которых размещен токен доступа). В некоторых случаях также возможен межплатформенный доступ, например, если одно приложение может получить доступ к журналам других приложений, оно может найти там токен, как указано в ошибке fb lib.
— Игорь Кордаш
16

У меня был тот же вопрос, что и в вопросе 1 здесь, и я недавно провел небольшое исследование, и я пришел к выводу, что это нормально - не держать в секрете «секрет клиента». Тип клиентов, которые не сохраняют конфиденциальность секрета клиента, в спецификации OAuth2 называется «публичный клиент». Вероятность того, что кто-то злоумышленник сможет получить код авторизации, а затем токен доступа, предотвращается следующими фактами.

1. Клиенту необходимо получить код авторизации напрямую от пользователя, а не от сервиса.

Даже если пользователь указывает службу, которой он / она доверяет клиенту, клиент не может получить код авторизации от службы, просто указав идентификатор клиента и секрет клиента. Вместо этого клиент должен получить код авторизации непосредственно от пользователя. (Обычно это делается с помощью перенаправления URL, о чем я расскажу позже.) Итак, для злонамеренного клиента недостаточно знать идентификатор / секрет клиента, которому доверяет пользователь. Он должен как-то вовлечь или обмануть пользователя, чтобы дать ему код авторизации, что должно быть сложнее, чем просто знать идентификатор / секрет клиента.

2. URL-адрес перенаправления зарегистрирован с идентификатором / секретом клиента.

Предположим, что злоумышленнику каким-то образом удалось вовлечь пользователя и заставить его нажать кнопку «Авторизовать это приложение» на странице сервиса. Это вызовет ответ перенаправления URL-адреса от службы в браузер пользователя с кодом авторизации с ним. Затем код авторизации будет отправлен из браузера пользователя на URL-адрес перенаправления, и предполагается, что клиент прослушивает URL-адрес перенаправления для получения кода авторизации. (URL-адрес перенаправления тоже может быть localhost, и я решил, что это типичный способ, которым «общедоступный клиент» получает код авторизации.) Поскольку этот URL-адрес перенаправления зарегистрирован в службе с идентификатором / секретом клиента, злонамеренный клиент не есть способ контролировать, где предоставляется код авторизации.

— Хидеаки
источник
3
Это многообещающе, у вас есть какие-нибудь рекомендации по этому поводу? Было бы обнадеживающе узнать.
— Гаут,
1
В документации по Диску я видел, что в установленных приложениях секрет клиента на самом деле не является секретом, но они не объяснили, почему его можно хранить там. Ваше объяснение очень помогло!
— Мартин Спасов
1

Отвечая на второй вопрос: API Google по соображениям безопасности предписывают, что аутентификация / вход в систему не может выполняться в самом приложении (например, веб-просмотр не разрешен) и должен выполняться вне приложения с использованием браузера для большей безопасности, что дополнительно объясняется ниже: https: //developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html

— vj
источник
по крайней мере, это «исправлено» через 3 года после того, как я спросил :)
— Bear
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.