Невидимка вк авторизация: vkontakte api — VK api — Как скрыть статус «online» авторизированного пользователя?

Теперь злоумышленник может в любое время войти в учетную запись такси жертвы, так как она привязана к [email protected] . Атака входа в систему CSRF позволила злоумышленнику украсть учетную запись.

Атаки CSRF обычно отбиваются с помощью токена CSRF (его также называют state ), и OAuth 2.0 не является исключением. Как использовать токен CSRF:

1. Клиентское приложение генерирует и сохраняет токен CSRF на мобильном устройстве клиента.
   
2. Клиентское приложение включает токен CSRF в код запрос доступа.
   
3. Сервер возвращает тот же токен CSRF с кодом в ответе.
   
4. Клиентское приложение сравнивает входящие и сохраненные токены CSRF. Если их значения совпадают, процесс продолжается.
   

Вкратце, токен CSRF позволяет клиенту приложения ответить на вопрос: «Это я инициировал access_token запрос или кто-то пытается меня обмануть?».

Жестко закодированный секрет клиента

Влияние раскрытия client_id и client_secret сильно зависит от того, насколько поставщик услуг доверия доверяет определенному client_id , client_secret пара. Одни используют их только для того, чтобы отличить одного клиента от другого, в то время как другие открывают скрытые конечные точки API или устанавливают более мягкие ограничения скорости для некоторых клиентов.

В статье «Почему ключи и секреты API OAuth небезопасны в мобильных приложениях» более подробно рассматривается эта тема.

Вредоносное приложение, действующее как законный клиент

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

К сожалению, если механизм OAuth 2.0 использует поток через браузер, защититься от этой атаки невозможно.

Другие атаки

Хорошо, плохо OAuth 2.0

Первый способ — через пользовательскую вкладку браузера (слева на картинке). Примечание : Пользовательская вкладка браузера для Android называется Chrome Custom Tab, а для iOS — SafariViewController. В приложении отображается только вкладка браузера: визуального переключения между приложениями нет.

Второй способ - через WebView (справа на картинке) и я считаю его плохим по отношению к мобильному OAuth 2.0.

WebView — встроенный браузер для мобильного приложения.

" Встроенный браузер " означает, что доступ к файлам cookie, хранилищу, кешу, истории и другим данным Safari и Chrome запрещен для WebView. Верно и обратное: Safari и Chrome не могут получить доступ к данным WebView.

" Браузер мобильного приложения " означает, что мобильное приложение, которое запускает WebView, имеет полный доступ к файлам cookie, хранилищу, кешу, истории и другим данным WebView.

А теперь представьте: пользователь нажимает «войти с…», и WebView вредоносного приложения запрашивает его логин и пароль у поставщика услуг.

Эпический фейл:

1. Пользователь вводит свой логин и пароль от учетной записи поставщика услуг в приложении, которое может легко украсть эти данные.
   
2. OAuth 2.0 изначально был разработан для , чтобы не вводить логин и пароль поставщика услуг.
   
   Пользователь привык вводить свой логин и пароль где угодно, тем самым увеличивая возможность рыбалки.
   

Если у кого-то есть аргументы в пользу WebView вместо Custom Tab Browser, буду признателен, если вы напишете об этом в комментариях.

Безопасная мобильная схема OAuth 2.0

Источник изображения: https://tools.ietf.org/html/rfc8252#section-4.1

Код запроса доступа (шаги 1-2) будет выглядеть следующим образом:

 https://o2.mail.ru/code?
redirect_uri=com.mail.cloud.app%3A%2F%2Foauth&
состояние = 927489cb2fcdb32e302713f6a720397868b71dd2128c734181983f367d622c24& code_challenge = ZjYxNzQ4ZjI4YjdkNWRmZjg4MWQ1N2FkZjQzNGVkODE1YTRhNjViN jJjMGY5MGJjNzdiOGEzMDU2ZjE3NGFiYw%3D%3D&
code_challenge_method=S256&
область = электронная почта% 2Cid &
response_type=код&
client_id=984a644ec3b56d32b0404777e1eb73390c 

 com.mail.cloud.app://oаuth?
код = b57b236c9bcd2a61fcd627b69ae2d7a6eb5bc13f2dc25311348ee08df43bc0c4&
состояние = 927489cb2fcdb32e302713f6a720397868b71dd2128c734181983f367d622c24 

 https://o2.mail.ru/token?
code_verifier = e61748f28b7d5daf881d571df434ed815a4a65b62c0f90bc77b8a3056f174abc&
код = b57b236c9bcd2a61fcd627b69ae2d7a6eb5bc13f2dc25311348ee08df43bc0c4&
client_id=984a644ec3b56d32b0404777e1eb73390c 

Эта схема в целом безопасна, но в некоторых особых случаях OAuth 2.0 может быть проще и безопаснее.

Android IPC

1. Приложение, открывающее канал IPC, может подтвердить подлинность открываемого приложения с помощью своего сертификата. Верно и обратное: открытое приложение может подтвердить подлинность открывшего его приложения.
   
2. Если отправитель отправляет запрос по каналу IPC, он может получить ответ по тому же каналу. Вместе с перекрестной проверкой (пункт 1) это означает, что ни один посторонний процесс не может перехватить access_token .
   

Таким образом, мы можем использовать Implicit Grant для упрощения схемы мобильного OAuth 2.0. № code_challenge и state также означают меньшую поверхность атаки. Мы также можем снизить риск того, что вредоносные приложения будут действовать как законный клиент, пытаясь украсть учетные записи пользователей.

SDK для клиентов

1. Прочная основа имеет решающее значение. В случае мобильного OAuth 2.0 основой является схема или протокол, выбранный для реализации. Легко допустить ошибку при реализации собственной схемы OAuth 2.0. Другие уже получили удары и усвоили урок; нет ничего плохого в том, чтобы учиться на их ошибках и выполнять безопасную реализацию за один раз. Самая безопасная схема мобильного OAuth 2.0 описана в Как сделать это безопасно ?
   
2. Access_token и другие конфиденциальные данные должны храниться в связке ключей для iOS и во внутреннем хранилище для Android. Эти хранилища были специально разработаны именно для этого. Content Provider можно использовать в Android, но он должен быть надежно настроен.
   
3. Client_secret бесполезен , если только он не хранится в бэкенде. Не отдавайте его публичным клиентам.
   
4. Не использовать WebView для экрана согласия; используйте пользовательскую вкладку браузера.
   
5. Для защиты от перехвата кода используйте code_challenge .
   
6. Для защиты от CSRF OAuth 2.0 используйте состояние .
   
7. Использовать HTTPS везде , переход на HTTP запрещен. Вот 3-минутная демонстрация, объясняющая, почему (на примере вознаграждения за обнаружение ошибок).
   
8. Следуйте стандартам криптографии (выбор алгоритма, длины токенов и т. д.). Вы можете скопировать данные и выяснить, почему это сделано именно так, но не запускайте собственную крипту.
   
9. Код должен использоваться только один раз, с коротким сроком службы.
   
10. Со стороны клиента приложения проверьте, что вы открываете для OAuth 2,0; а со стороны поставщика приложений проверьте, кто открывает вас для OAuth 2.0.
    
11. Помните о распространенных уязвимостях OAuth 2.0. Мобильный OAuth 2.0 расширяет и дополняет исходный, поэтому redirect_uri проверяют на точное совпадение и другие рекомендации для исходного OAuth 2,0 остаются в силе.
    
12. Вы должны предоставить своим клиентам SDK. У них будет меньше ошибок и уязвимостей, и им будет проще внедрить ваш OAuth 2. 0.
    

1. «Уязвимости мобильного OAuth 2.0» https://www.youtube.com/watch?v=vjCF_O6aZIg
   
2. Исследование условий гонки OAuth 2.0 https://hackerone.com/reports/55140
   
3. Почти все об OAuth 2.0 в одном месте https://oauth.net/2/
   
4. Почему ключи и секреты API OAuth небезопасны в мобильных приложениях https://developer.okta.com/blog/2019/01/22/oauth-api-keys-arent-safe-in-mobile-apps
   
5. [RFC] OAuth 2.0 для собственных приложений https://tools.ietf.org/html/rfc8252
   
6. [RFC] Ключ подтверждения для обмена кодами публичными клиентами OAuth https://tools.ietf.org/html/rfc7636
   
7. [RFC] Модель угроз OAuth 2.0 и вопросы безопасности https://tools.ietf.org/html/rfc6819
   
8. [RFC] Протокол динамической регистрации клиентов OAuth 2.0 https://tools.ietf.org/html/rfc7591
   
9. Google OAuth 2.0 для мобильных и настольных приложений https://developers.