Приложение для iPhone с серверным бэкэндом. Как обеспечить весь доступ только из приложения iPhone?

Question

Я не особо беспокоюсь о пиратстве и так далее, но я хочу убедиться, что бэкэнд (на основе Rails) не открыт для автоматизированных сервисов, которые могли бы его использовать DOS и т.д. к бэкэнду (который будет представлять собой несколько запросов REST к данным GET и PUT) будет через действующее приложение iPhone, а не какой-либо скрипт, работающий на машине.

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

Мое первое намерение - объединить UDID и секрет вместе и предоставить его (и UDID) через HTTPS-соединение с сервером. Это либо позволит создать аутентифицированный сеанс, либо вернет ошибку.

Если подслушано, то злоумышленник может взять хэш и воспроизвести его, оставив эту схему открытой для повторных атак. Однако не должно ли HTTPS-соединение защищать меня от перехвата?

Спасибо!

Answer 1

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

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

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

Answer 2

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

Я не могу дать подробности кода для Rails, но с точки зрения архитектуры это наиболее безопасный способ сделать, хотя это может быть немного излишним. SSL с сертификатами является стандартным отраслевым решением, и библиотеки существуют как для iPhone / клиента, так и для сервера, поэтому вам не нужно ничего придумывать или реализовывать, просто заставьте их работать вместе.

Вы могли бы также рассмотреть HMAC, как HMAC-SHA1, который в основном является стандартизацией хеш-содержимого, о котором говорят другие люди. Если вы добавите в него одноразовые номера, вы также будете защищены от повторной атаки. Чтобы получить представление о том, как реализовать HMAC-SHA1 с одноразовыми номерами, вы можете взглянуть на протокол OAuth (не весь поток, а только то, как они связывают одноразовые и другие параметры вместе в аутентифицированный запрос).

Answer 3

Нет никакого способа гарантировать это, так как это может быть подделано.

Если вы действительно хотите пойти по этому пути (если честно, если вы здесь не делаете что-то действительно сверхмалое, вы, вероятно, теряете время), вы можете передать токен устройства iPhone. Или, может быть, хэш, а затем передать его. Конечно, у вас нет возможности проверить это на стороне сервера или что-то в этом роде, но если плохой парень действительно хочет вас убить, вот контрольно-пропускной пункт № 1, с которым ему придется сначала разобраться.