Как я могу проверить подлинность запросов от приложения iphone к моему веб-сервису - PullRequest
3 голосов
/ 08 июля 2010

Я бы хотел отправлять запросы из приложения для iphone на созданный мной веб-сервис.Как я могу проверить, что запросы к веб-службе поступают из моего приложения для iphone (или даже из любого авторизованного источника) и не подделаны?

Я посмотрел на базовую аутентификацию через HTTPS, но выпекает учетные данные в приложении безопасно?

Этот вопрос на самом деле не относится к iphone;Я хотел бы знать, как защитить и аутентифицировать запросы в целом.

Ответы [ 2 ]

2 голосов
/ 08 июля 2010

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

В iPhone нет сканеров сетчатки или отпечатков пальцев, поэтому что-то не существуету вас есть «доступные варианты».

Сертификаты клиента работают как токен «что-то, что у вас есть».Большинство смарт-карт работают, подписывая сообщение встроенным сертификатом.Когда сертификат скомпрометирован, его можно поместить в список отзыва сертификатов (CRL), на который ссылаются веб-серверы.Очевидно, что вы не захотите помещать встроенный сертификат вашего приложения в CRL - это лишит доступа всех ваших пользователей.Вместо этого вы захотите, чтобы пользователи загружали отдельные сертификаты на свои iPhone.

После этого необходимо следить за необычным поведением, чтобы найти плохих актеров и добавить эти сертификаты в CRL.Два мертвых подарка - это клиенты, которые отправляют слишком много запросов одновременно или со слишком большого количества разных IP-адресов за слишком короткое время.

Логин / пароль - это простой токен «что-то, что вы знаете».Как и сертификаты, комбинации логин / пароль могут быть скомпрометированы, и подобный мониторинг может быть настроен для обнаружения неподобающего поведения.Разница в том, что скомпрометированные учетные записи будут помечены как заблокированные, а не добавлены в CRL.

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

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

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

1 голос
/ 08 июля 2010

Теоретически, если вы хотите, чтобы соединение было безопасным, лучше всего, чтобы клиент подписал свой запрос с помощью сертификата.Есть несколько ресурсов об этом.Ищите «сертификат клиента» в Google.

Этот пример с Sun написан на Java, но концепция схожа с любым языком.

PS: очевидно, это нене мешают вам использовать другие методы аутентификации, такие как пароли и т. д.

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

...