Безопасное приложение для iPhone ↔ общение с сервером

Каков наилучший подход для достижения личной связи между моим приложением iOS и его серверным компонентом? Достаточно ли запекания одного неизменного «секретного ключа» в исходный код приложения или мне нужно каким-то образом динамически настраивать поколения таких «рукопожатых» ключей?

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

Серверный компонент работает на RoR, если это важно.

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

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

Предположим, у вас есть переход по URL, который может принести вам ощутимую стоимость (например, стоимость обработки), и вы хотите защитить его как от простой DoS-атаки, так и от приложений подражателя.

Используйте SSL, чтобы скрыть соединение от простого анализа. Используйте номер порта non-obviuos, последовательность перенаправления, обмен файлами cookie, чтобы немного усложнить соединение, прежде чем выполнять дорогостоящую часть запроса. Используйте некоторый секретный код, встроенный в ваше приложение, чтобы сервер знал, что он должен принять соединение.

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

Вы не можете реально защитить свой код от декомпиляции и / или запуска под отладчиком. В конечном итоге злоумышленник узнает секретный ключ и последовательность подключения.

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

Создайте бесплатное незначительное обновление вашего приложения с другим секретным ключом. Он должен попадать на другой дорогой URL, который обслуживает те же данные, что и скомпрометированный дорогой URL. В течение некоторого времени сделайте оба URL доступными.

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

Отказ от ответственности: я не эксперт по безопасности.

У вас есть классическая проблема, которая действительно не может быть решена.

Чтобы обеспечить простую конфиденциальность (т. Е. Убедиться, что ваши данные не могут быть отслежены или изменены при передаче), вы можете делать все через SSL и предоставлять вашему серверу правильно выданный сертификат от CA, который распознает iPhone.

Однако для авторизации не существует хорошего решения, которое на 100% гарантирует, что никто, кроме вашего приложения, не сможет получить доступ к API. Ваше предлагаемое решение будет работать, кроме:

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

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

Для этого и нужны TLS и SSL . Либо можно создать безопасное соединение без необходимости фиксированного секретного ключа. Прочтите раздел «Описание» на связанной странице, чтобы узнать, как они это делают.

Эффективный способ получить преимущества TLS / SSL без необходимости выполнять большую (любую) работу - заставить ваш сервер реализовать веб-службу, к которой клиент обращается по протоколу HTTPS. HTTPS - это просто HTTP через безопасное соединение, и система загрузки URL-адресов в iOS реализует его для вас.