приложение для iPhone с Бэкендом Сервера - Как гарантировать весь доступ, из приложения для iPhone только?
Я не возражаю так об ограблении и так далее, но я хочу удостовериться, что бэкенд (Базирующиеся направляющие) не открыт для автоматизированных сервисов, которые могли DOS это и т.д. Поэтому, я хотел бы просто удостовериться, что весь доступ к бэкенду (который будет несколькими запросами REST, чтобы ПОЛУЧИТЬ и ПОМЕСТИТЬ данные) будет с помощью действительного приложения для iPhone и не некоторого сценария, работающего на машине.
Я хочу избежать использования учетных записей так, чтобы пользовательский опыт был бесшовным.
Мое первое намерение состоит в том, чтобы хешировать UDID и секрет вместе, и обеспечить что (и UDID) по Подключению HTTPS к серверу. Это или позволит аутентифицируемой сессии быть созданной или возвратит ошибку.
Если подслушано, то взломщик мог взять хеш и воспроизвести его, оставив эту схему открытой для атак с повторением пакетов. Однако Разве Подключение HTTPS не должно защищать меня от подслушивания?
Спасибо!
3 ответа
Как говорит bpapa, его можно подделать, но тогда, как вы говорите, вы не беспокоитесь об этом так сильно, как любой, кто приходит и просто отправляет тысячу запросов на ваш сервер подряд, и ваш сервер должен обрабатывать каждый из них.
Ваше представление о хэше - хорошее начало. Оттуда вы также можете добавить текущую метку времени к предварительно хэшированной стоимости и отправить ее вместе. Если заданная метка времени более чем на 1 день отличается от текущего времени сервера, запретите доступ. Это останавливает повторные атаки более чем на день позже.
Другим вариантом было бы использование nonce. Любой может запросить nonce с вашего сервера, но затем устройство должно добавить его к предварительным хэш-данным перед отправкой хэша на сервер. Сгенерированные nonces должны быть сохранены или могут быть просто текущей меткой времени сервера.Затем устройство должно добавить метку времени сервера вместо собственной метки времени к предварительно хэшированным данным, что позволяет использовать гораздо более короткий период, чем полный день, для повторной атаки.
Использовать SSL с сертификатом клиента. Имейте закрытый ключ в своем клиенте и выпускайте для него сертификат, и ваш веб-сервер может потребовать, чтобы этот сертификат клиента присутствовал для продолжения сеансов.
Я не могу сообщить подробности кода для Rails, но с точки зрения архитектуры это наиболее безопасный вариант, хотя он может быть немного излишним. SSL с сертификатами является стандартным отраслевым решением, и библиотеки существуют как для iPhone / клиента, так и для сервера, поэтому вам не нужно ничего изобретать или внедрять, просто заставьте их хорошо работать вместе.
Вы также можете рассмотреть HMAC, например HMAC-SHA1, который в основном представляет собой стандартизацию хешей, о которой здесь говорят другие люди. Если вы добавите к нему одноразовые номера, вы также будете защищены от атаки повторного воспроизведения. Чтобы получить представление о том, как реализовать HMAC-SHA1 с одноразовыми номерами, вы можете посмотреть протокол OAuth (не весь поток, а только то, как они связывают одноразовые номера и другие параметры вместе в аутентифицированном запросе).
Нет никакого способа обеспечить его, так как его можно подделать.
Если вы действительно хотите пойти по этому пути (честно говоря, если вы не делаете что-то действительно супер критически важное здесь, вы, вероятно, тратите свое время), вы можете передать токен устройства iPhone. Или, может быть, хэш, а затем передать его. Конечно, у вас нет возможности проверить его на стороне сервера или что-то еще, но если плохой парень действительно хочет вас сбить, вот препятствие #1, с которым ему придется иметь дело в первую очередь.