Лучшая практика для определения доступа приложения iPhone только для веб-служб?

Question

Я разрабатываю приложение для iPhone вместе с веб-сервисами. Приложение iPhone будет использовать GET или POST для извлечения данных из веб-сервисов, таких как http://www.myserver.com/api/top10songs.json, например, для получения данных о первой десятке песен.

Для приложения iPhone нет учетной записи и пароля. Лучше всего убедиться, что только мое приложение iPhone имеет доступ к веб-API http://www.myserver.com/api/top10songs.json? UIDevice uniqueueIdentifier iPhone SDK недостаточно, поскольку любой может подделать идентификатор устройства в качестве параметра, совершая вызов API с помощью wget, curl или web браузеры.

API веб-сервисов не будет опубликован. Данные веб-сервисов не являются секретными и частными, я просто хочу предотвратить злоупотребление, поскольку есть также API для записи некоторых данных на сервер, таких как журнал использования.

Answer 1

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

Answer 2

Вот расширение предложения Даниила.

Имейте некоторый общий секрет, который знает сервер и клиент. Скажи какую-нибудь длинную случайную строку.

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

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

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

Answer 3

Я спросил об этом инженера по безопасности Apple на WWDC, и он сказал, что нет неопровержимого способа сделать это. Лучшее, что вы можете сделать, это сделать так, чтобы оно того не стоило.

Я также спросил его о возможном использовании push-уведомлений в качестве средства для этого, и он подумал, что это очень хорошая идея. Основная идея заключается в том, что при первом доступе на вашем сервере будет отправлено push-уведомление, которое будет отправлено на iPhone пользователя. Поскольку ваше приложение открыто, оно будет вызывать метод application:didReceiveRemoteNotification: и доставлять полезную нагрузку по вашему выбору. Если вы сделаете эту полезную нагрузку одноразовым, то ваше приложение может отправить одноразовый номер по следующему запросу, и вы завершили круг.

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

Answer 4

Используйте некоторую форму цифровых подписей в вашем запросе. Хотя сделать это полностью защищенным от несанкционированного доступа довольно сложно (как и все, что касается безопасности). Это не так сложно получить «достаточно хорошо», чтобы предотвратить большинство злоупотреблений.

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

Answer 5

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

Простое решение может заключаться в простом использовании HTTPS - обеспечение безопасности ваших сообщений, несмотря на присутствие потенциальных перехватчиков, - вот и весь смысл HTTPS. Я не уверен, что вы можете создавать самозаверяющие сертификаты со стандартным NSURLConnection, но если у вас есть сертификат на стороне сервера, вы, по крайней мере, защищены от прослушивания. И кода для написания гораздо меньше (на самом деле, нет).

Полагаю, если вы используете HTTPS в качестве единственной защиты, то вы потенциально открыты для того, чтобы угадать URL. Если это вызывает озабоченность, то добавление практически любого вида проверки параметров в веб-службу позаботится об этом.

Answer 6

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

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

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

Answer 7

Имейте некоторый ключ, который меняется каждые 5 минут на основе алгоритма, который использует текущее время (GMT). Всегда позволяйте вводить последние два ключа. Конечно, это не идеально, но это заставляет цель двигаться, и вы можете комбинировать ее с другими стратегиями и тактиками.

Полагаю, вы просто хотите отговорить использование вашего сервиса. Очевидно, вы не настроили свое приложение для обеспечения безопасности.

Answer 8

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