Лучшие практики борьбы со злоупотреблением пользовательской схемой URL для проведения фишинговых атак ios

Мы должны предположить, что вредоносное приложение может перехватить любые данные, включенные в этот URL-адрес, и что его автор может свободно перепроектировать любое поведение, включенное в ваше приложение, чтобы оно могло имитировать ваш пользовательский интерфейс и любую проверку, которую пытается выполнить ваше приложение. Однако мы также можем предположить, что вредоносное приложение содержится в собственной изолированной программной среде, поэтому ваше приложение может в частном порядке взаимодействовать с вашим бэкэндом. Вредоносное приложение может имитировать любое такое общение, но это позволяет нам создать секрет, неизвестный вредоносному приложению. Это дает нам, по крайней мере, возможность разработать некоторые контрмеры.

Один из вариантов может быть:

1. В рамках регистрации создайте пару открытого и закрытого ключей и сохраните ее в своем приложении.
2. Отправьте открытый ключ на свой веб-сервер в рамках процесса регистрации.
3. Кодируйте полезную нагрузку вашего URL-адреса, используя этот открытый ключ.

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

Закодированные данные могут быть токеном, который мы можем использовать для аутентификации пользователя и, следовательно, никогда не требовать от него повторной аутентификации в приложении. Тогда нет экрана входа в систему, который можно было бы имитировать (хотя умной подделки может быть достаточно, чтобы обмануть пользователей и заставить их раскрыть свои учетные данные).

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

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

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

Попробуйте что-то вроде этого:

В своем электронном письме укажите, что нажатие на URL-адрес запустит приложение и вы войдете в систему в первый раз, а затем предложите пользователю ввести новый пароль. Включите токен в URL-адрес, который при обработке вашим приложением выполняет однократный вход в систему и переводит пользователя на страницу «Новый пароль».

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

edit: подумав об этом дальше, пока у вас есть активный злоумышленник, вы в значительной степени облажались. Злоумышленник может продолжать эмулировать ваше приложение, эффективно используя MITM, независимо от того, что вы делаете, пока он может перехватить этот первоначальный URL-адрес. Мое решение будет работать только в самых простых случаях, не очень надежно.