Comments 6
Юра, привет! Интересная статья. Так получилось, что я сам недавно проводил подобное же исследование, даже подумывал о своей собственной статье, но как обычно, не хватает на все времени - напишу здесь, так как случай интересный и на мой взгляд, может привести к реальной угрозе:
Выполнял секюрити ревью мобильного приложение заказчика, и обратил внимание что в трафике прилетает OAuth2.0 Auth Code в диплинке, написал свой POC, подписавшись на схему в диплинке, получилось перехватить запрос приложения, и если выбрать мой POC то удавалось стянуть AuthCode. Но сам код все же бесполезен, без CodeVerifier так как используется PCKE, однако я решил подумать дальше, что тут можно сделать.
И придумал следующее. Если мы создаем малишес приложение, замаскированное под что то полезное, то в процессе аутентификации в наше хорошее приложение возникает неожиданное окно с выбором приложение, и если пользователь ошибся и выбрал неправильное приложение (например название похожее и значок), то открылось наше приложение, в котором мы имитируем форму авторизации, на которой только что находился пользователь (так что для него нет в этом неожиданности), и показываем фейковое сообщение, что "Ошибка авторизации, авторизуйтесь еще раз". Пользователь вводит свои креды, и все они утекли.
Как кейс, на мой взгляд выглядит валидным. Из за особенности реализации используется именно диплинк и само событие по вызову диплинки не рандомное, а вполне конкретное и пользователь не будет удивлен несвоевременностью запроса кредов.
Со всем согласен с написанным, хотел добавить один момент, не упомянутый в статье, для митигации этой и подобных проблем:
Как механизм защиты от подобных манипуляций с диплинками, для приложений, хорошим решением будет при запуске приложения, выполнять проверку на наличие на этом устройстве других приложений, подписанных на диплинку, которая уникальна для нашего приложения с помощью PackageManager.queryIntentActivities и при обнаружении либо вывести предупреждение для пользователя о наличии проблемы безопасности, либо полностью заблокировать запуск.
Надеюсь мой комментарий немного дополнит твою прекрасную заметку.
Спасибо за статью.
Единственное, чего нам удалось добиться — это превращение App Links в обычные Web Links, которое влечет за собой появление диалога "устранения неоднозначности".
Можете, пожалуйста, раскрыть этот момент? Злоумышленник сможет сделать это, не имея доступа к нашему беку?
Участие в процессе верификации google это к сожалению тоже по нынешним временам - проблема безопасности. Будет ли работать механизм если установить приложение из Rustore?
Такие разные Android AppLinks, WebLinks, DeepLinks. Разбираемся и пытаемся сломать