Описанный ниже метод защиты был взломан, читайте продолжение этого поста: Защита от взлома встроенных покупок.
Часть 2 .
Не так давно была новость об активации внутриигровых покупок бесплатно и даже без джейлбрейка.
Идея проста: в системе устанавливаются SSL-сертификаты и регистрируется собственный DNS-сервер, который будет перенаправлять запросы к серверам Apple на сервер злоумышленников.
Хакерский сервер подтвердит покупку, и она будет успешно активирована на устройстве.
После выхода этой новости возникла большая паника и Apple даже пришлось что-то делать и расскажите разработчикам, как защитить свое приложение .
На самом деле проблема не была новой; уже давно можно бесплатно активировать внутриигровые покупки на взломанных устройствах.
Решение проблемы тоже не новое, оно описано в документации Apple, но практической реализацией никто не заморачивался.
Мой вариант такой защиты будет рассмотрен ниже.
Как работают покупки в приложении.
Есть два возможных сценария.
Простой: 
Устройство активирует покупку через сервер Apple без дополнительной валидации и участия сервера разработчика.
Трудный: 
Сервер разработчика может участвовать в процессе покупки следующим образом: отправляет список возможных покупок (шаг 2),
проверяет проверку файлов cookie (шаги 10–11),
обеспечивает доступ к некоторому дополнительному контенту (шаги 13–14).
Нас интересуют шаги 10-11, потому что.
Именно по ним мы можем помочь устройству определить, выдан ли чек сервером Apple или это подделка.
Здесь следует добавить, что исходный код из статьи Apple может помочь с проверкой квитанции непосредственно из приложения, но эта защита не является надежной, поскольку никто не мешает вам перенаправлять запросы на проверяющий сервер на адрес злоумышленников.
'сервер, который вернет ожидаемый ответ.
Проверка
Мы можем проверить квитанцию о покупке только на сервере Apple. Для этого вам нужно отправить JSON с квитанцией, закодированной в base64, внутри запроса HTTP POST: {
"receipt-data" : "(receipt bytes here)"
}На один из серверов Apple: sandbox.itunes.apple.com/verifyReceipt — для тестовых покупок из песочницы buy.itunes.apple.com/verifyReceipt — для покупок в AppStore. В ответ сервер вернет статус валидации и, если валидация прошла успешно, расшифрованные поля квитанции:
{
"status" : 0,
"receipt" : { (receipt here) }
}От теории к практике
Понимая описанную выше механику, не составило труда написать на Ruby прокси-приложение, которое перенаправляет запросы на валидацию на один из серверов Apple. Я разместил его готовым к использованию код приложения на GitHub .Буду рад улучшениям и пул-реквестам.
Вы также можете коснуться его на Heroku: https://receiptValidator.heroku.com/validate с использованием тестовая проверка из репозитория.
С флажком песочницы вы можете увидеть правильный ответ, а без него — код ошибки.
В приложении мы анализируем ответ нашего сервера и решаем, стоит ли активировать встроенные функции или это подозрительная проверка и ее можно игнорировать.
Если вам интересно, в следующей статье я напишу о защите внутри приложения.
Нижняя граница
Проверка покупок через ваш сервер делает приложение «специальным» и универсальные прерыватели перестают работать.Взломать приложение все еще возможно, но для этого нам нужно взломать наше приложение.
Если кто-то найдет время взломать ваши покупки, вы можете добавить дополнительное шифрование при общении с нашим сервером.
Бесплатно на героку мы получаем удобный рубиновый хостинг и https-шифрование.
P.S. Немного беспардонной саморекламы: эта защита написана специально для Офлайн-карты Галилео и был успешно протестирован в версии 2.2, появившейся в Магазин приложений Вчера утром.
Теги: #в приложении #проверка квитанции #Apple #iOS #ruby #heroku #информационная безопасность #разработка iOS
-
Мы Пытаемся Открыть Свой Бизнес. Часть 2
19 Oct, 24 -
Я Буду Учиться В Центре Компьютерных Наук
19 Oct, 24 -
Твердые Носители
19 Oct, 24
