• GraphQL Voyager как инструмент для поиска уязвимостей
    0
    Хорошо использовать данный инструмент как дополнительный, но не заменять JSON.

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


    Теперь стало намного понятнее

    Конкретно эта фраза скорее шутка, потому что схему выше с первого взгляда трудно назвать легкой и понятной :)

  • Безопасность мобильного OAuth 2.0
    0
    Конечно же нет. Рекомендация про WebView направлена на то, чтобы максимально обезопасить пользователя и облегчить ему вход в приложение. Если у него есть сессия в браузере, то эта сессия сразу подхватится, соответственно никаких данных пользователь вводить не будет. В случае с WebView пользователю всегда придется вводить логин и пароль, следовательно повышается вероятность, что пользователь когда-то введет логин и пароль в зловредном приложении.
  • Безопасность мобильного OAuth 2.0
    0
    А зачем? Пользователь не должен (и вряд ли будет) искать глазами и разбираться что перед ним: WebView или Browser Custom Tab. Смысл использования Browser Custom Tab в том, что он безопаснее и может подхватить уже существующую сессию пользователя.
  • Безопасность мобильного OAuth 2.0
    0
    В этом сценарии легитимное приложение не участвует. Зловредное приложение регистрируется как обычный OAuth 2.0 клиент (например, у Google можно легко зарегистрировать свой OAuth 2.0 клиент через веб-интерфейс), может быть даже какое-то время работает в нормальном режиме и не приносит вреда, но при этом оно всегда имеет возможность прочитать логин и пароль пользователя, если тот авторизуется по OAuth 2.0 через WebView (WebView будет поднято в зловредном приложении, но с точки зрения SDK это обычный OAuth 2.0 клиент).
  • Безопасность мобильного OAuth 2.0
    0
    Злоумышленник перехватил code (одновременно с искажением state), и хочет получить access_token.




    А в каком случае злоумышленник может перехватить code и исказить state, но при этом не может просто прервать запрос пользователя? Я вижу вариант, когда злоумышленник MitM-ит пользователя, но в этом случае он может и другими способами прервать запрос за access_token.

    Т.е., условно говоря, юзер скачал где-то мобильное приложение, притворяющееся настоящим клиентом, запустил его, оно использовало client_id настоящего клиента для получения доступа. Немного напоминает «я бедный африканский хакер» в топике про вирусы под линух, ну да ладно. Но где в этой картине второй, настоящий клиент?


    

Да, все так. Настоящего клиента может и не быть, суть атаки именно в том, что зловред показывает чужой consent screen, а пользователь из-за невнимательности фишится. Вектор атаки не супер критичный, но все равно я думаю, что лучше его учесть и принять меры защиты.

    «This specification is designed for use with HTTP ([RFC2616]). The use of OAuth over any protocol other than HTTP is out of scope.»




    Это можно трактовать как «OAuth 2.0 должен использоваться только вместе с HTTP», так и как «OAuth 2.0 разрабатывался для HTTP, любые другие транспорты вы используете на свой страх и риск». Я больше склоняюсь ко второй. При использовании транспортов отличных от HTTP нужно учитывать уязвимости, которые транспорт привнесет вместе с собой, и тщательно проверять на безопасность. Называть получившийся после замены транспорта протокол OAuth-ом или не называть, на мой взгляд, уже холиварный вопрос.
  • Безопасность мобильного OAuth 2.0
    0
    На Android приложение может проверить какой браузер оно открывает и разрешать только браузеры из белого списка. В нашем OAuth 2.0 SDK для клиентов такая функция есть, я не указал ее в статье. На iOS кастомные браузеры все равно используют Safari, поэтому проблем с зловредными браузерами там нет.

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

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

    Если приложение-клиент использует OAuth 2.0 через приложение-провайдер, то такая проверка возможна. Если же приложение-клиент использует OAuth 2.0 через браузер, то там обычный HTTP запрос и зловред может его подделать, потому что секреты в мобильном приложении безопасно не зашить (их можно проснифать или разреверсить).

    Поможет ли Attestation API  в данном случае сходу сказать не могу, нужно читать, разбираться и пробовать. Но за ссылку спасибо, посмотрю.
  • Безопасность мобильного OAuth 2.0
    0
    Откуда возьмутся такие устройства, на которых реально нет возможности реализовать SHA-256, но при этом есть возможность запускать свои OAuth-клиенты?

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

    Еще раз подчеркну, что если SHA-256 поддерживается, то нельзя делать даунгрейд до отсутствия преобразования code_verifier. Это указано и в статье, и в RFC 7636.

    Бывают атаки, которые намеренно искажают state отправляемый или получаемый легитимным клиентом (не уверен что мобильные, но для веб-клиентов я про такое читал) — делается это как раз для того, чтобы легитимный клиент остановился на этом этапе



    Интересно, не знал про подобные атаки. А для чего злоумышленнику останавливать клиента на этом этапе?

    Из описания не совсем понятен сценарий атаки, можете пояснить как конкретно это работает?

    У пользователя установлены два приложения: легитимное и зловред. Происходит следующее:
    1. Зловред поднимает consent screen легитимного приложения. Для этого зловреду достаточно передать client_id легитимного клиента.
    2. Невнимательный пользователь может разрешить доступ к своим ресурсам и подумать, что дает доступ легитимному приложению (на consent screen ведь иконка и название легитимного приложения), а в действительности он предоставит доступ зловреду.
    3. После этого зловред получит code, обменяет его на access_token и получит доступ к ресурсам пользователя.


    А разве использование IPC вместо HTTP не подразумевает автоматически, что это уже вообще не OAuth и не Implicit Grant, а просто какой-то свой простейший RPC-протокол 

    На мой взгляд, IPC это всего лишь транспорт (способ доставки) access_token, который заменяет HTTP. Протокол OAuth 2.0 показан на примере транспорта HTTP, потому что он наиболее популярен в вебе. Если посмотреть на описание Implicit Grant, то видно, что там не сказано, что транспортом обязательно должен быть HTTP.

    То что IPC из коробки может передать client_id и "redirect_uri" и по тому же соединению получить ответ — не делает его хуже HTTP.

    При использованием новых транспортов самое главное — учесть все возможные проблемы безопасности, связанные с транспортом. Хороший пример — кейс с использованием postMessage в реализации OAuth 2.0. Подчеркну, что сам по себе postMessage не является плохим транспортом, но необходимо учитывать возможные проблемы безопасности, которые он привносит.
  • Безопасность мобильного OAuth 2.0
    +1
    Ответ на первый вопрос. Приложение, которое подняло WebView, может получить доступ ко всем данным WebView, в том числе: логину/паролю, сессионным токенам пользователя. Если приложение легитимное и «доброе», то все хорошо. А вот если WebView поднимет зловред, то он легко может сфишить пользователя. Более подробно про этот и другие аргументы против WebView можно почитать в разделе «Хороший, плохой OAuth 2.0» этой статьи.

    По второму вопросу. У приложения может быть серверная часть, но кому-то дешевле оставить взаимодействие с токенами на стороне мобильного приложения. Не нужны сервера для хранения токенов и обработки запросов, не нужна разработка и тестирование серверного кода, не нужно заботиться о безопасности такой инфраструктуры. Это не отменяет тех случаев, когда OAuth 2.0 клиенты получают, используют и хранят access_token на сервере, а не в мобильном приложении. Оба варианта возможны и какой вариант использовать — это по большей части выбор OAuth 2.0 клиента (при условии, что OAuth 2.0 провайдер безопасно реализовал оба варианта на своей стороне).
  • Безопасность мобильного OAuth 2.0
    +1
    В этом кейсе бага была в браузере: он должен открывать Custom URI Scheme, но не делает этого. В таком случае нужно поступать как и со всеми багами — исправлять их. Всегда есть риск того, что на более низком уровене (браузер, операционная система, драйвера) будут баги или уязвимости, которые затронут работу приложения.

    Другое дело, если найдется браузер, для которого не открыть Custom URI Scheme — ожидаемое поведение, и при этом он будет достаточно популярным. В таком случае нужно задуматься путях решения проблемы или об альтернативах Custom URI Scheme.
  • Безопасность мобильного OAuth 2.0
    +1
    В приведенном тобой кейсе человек зарегистрировал за своим приложением схему «http», поэтому нет ничего удивительного, что некоторые браузеры не открывают такое приложение.

    В статье же речь идет о кастомной схеме (например, mailrumail), которая браузеру неизвестна.

    Я не сталкивался с ситуациями, когда браузеры полностью не поддерживают Custom URI Scheme. Если такие есть, можешь привести пример?