Как мой сервер может безопасно аутентифицировать покупку iPhone в приложении?

Ответ 1

Уязвимый подход Apple,

Сервер может аутентифицировать покупку выполнив следующие действия:

• Приложение iPhone получает transactionReceipt после покупки. Иметь iPhone base64 закодировать его (вы можете использовать этот open-source дополнение к NSData) и отправить его на ваш сервер. (Вы даже можете отправить его как есть, и сервер base64 кодирует его перед проверкой.)

• Попросите вашего сервера отправить запрос JSON с помощью одного ключа receipt-data с закодированным base64 transactionReceipt до https://buy.itunes.apple.com/verifyReceipt используя HTTP POST. (Инструкции о том, как это сделать на разных серверных языках см. Этот сайт)

• Сервер ответит с помощью объекта JSON двумя ключами: status, который является целым числом и receipt, который является повторением квитанции.

Если статус равен нулю, квитанция должна быть принята, ненулевое значение означает, что квитанция недействительна.

Безопасные дополнения к Apple Approach

Однако есть несколько последствий для безопасности. Пользователь может использовать другую пользовательскую квитанцию, поскольку устройства не привязаны к квитанциям, или пользователь может использовать другую квитанцию ​​продукта, так как сервер не проверяет идентификатор продукта квитанции. Чтобы этого не произошло, вы также должны сделать следующее:

• Когда вы впервые получите квитанцию ​​в приложении, немедленно отправьте ее на свой сервер вместе с UUID устройства через безопасный канал таких как HTTPS или SSL-сокет. Не храните его в любом месте, оставьте его в памяти.

• На вашем сервере сохраните пар UUID и квитанцию ​​в базе данных.

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

• Верните ответ на устройство по защищенному каналу, сообщив ему, есть ли покупка:

  • Аутентифицирован как новый (не был в БД и был действителен)
  • Аутентификация в прошлом (одинаковые UUID и квитанция уже были в БД)
  • Отказ от неправильного идентификатора продукта
  • Отказано из-за того, что он уже использовал квитанцию ​​с другим UUID.

Поскольку квитанция ведется только на памяти устройства, а ваше приложение использует UUID устройства ( может быть подделано jailbroken устройствами, см. комментарии), и все покупки вашего продукта регистрируются с UUID устройства на вашем сервере безопасным образом; пользователь не мог использовать другую квитанцию ​​пользователя для проверки покупки и не мог использовать квитанцию ​​от другого продукта, поскольку вы проверяете это.

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

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

Отказоустойчивость

Поскольку сбой может произойти между тем, когда пользовательское устройство получит квитанцию ​​и проверит ее с вашим сервером (например, если пользователь теряет связь или ваш сервер не работает для обслуживания), вы также должны позволить пользователю "повторно авторизировать", Повторная авторизация должна получить квитанцию ​​из магазина (с помощью Restored Transaction) и отправить его на сервер так же, как если бы это было новое покупка. Это редко нужно использовать, но должно быть доступно, чтобы сохранить пользователя, который должен повторно купить продукт в случае сбоя сети.

Рассмотрение нескольких устройств

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

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

Ответ 2

Я не думаю, что это может привязать квитанцию ​​на устройство.

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

Ответ 3

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

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

Ответ 4

UDID больше не работает

Ответ Бенио отличный, однако, в наши дни, как упоминал Джо Д'Арда, UDID устарел, и в последний раз, когда я пытался, приложение, которое использовало вызов для получения UDID, не смогло пройти проверку во время загрузки в iTunes.

Ограниченные по времени поступления в качестве альтернативы счетчикам приема

Чтобы добавить на hloupyhonza ответ, помимо наличия счетчика "запроса на загрузку" для конкретной квитанции, вы можете просто ограничить срок действия квитанции по времени. Я нашел что-то между 12 и 24 часами разумным.

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

Предотвращение взлома "Off-The-Shelf"

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

• информация о доставке json string
• Общий секретный ключ
• Код состояния успешной проверки.

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