Защита от атак для покупок iOS In-App

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

Я прочитал справочные документы StoreKit, доступные от Apple, и у меня есть общее представление о рабочем процессе и проверках, которые необходимо выполнить, и так далее. Однако могут возникнуть проблемы с безопасностью, о которых я не знаю.

Может ли кто-либо предоставить полный список краж-атак, которые могут быть предприняты против механизмов покупки In-App, как разработчики могут ошибочно разрешать эти атаки и какие методы лучше всего их предотвращать?

Ответ 1

Это те атаки, о которых я знаю, прошлые и настоящие:

Fake App Store

Прославленный российским программистом Алексей Бородин, эта атака затрагивает только приложения, которые проверяют поступления к покупке непосредственно в App Store. Изменяя параметры DNS на устройстве и устанавливая поддельные сертификаты безопасности, запросы проверки отправляются на фальшивый сервер App Store, который автоматически возвращает, что покупка действительна. Неприемлемые приложения будут принимать эти контрольные вызовы и доставлять контент пользователю.

Комментарий

После того, как этот эксплойт был объявлен в июле 2012 года, Apple выпустила обновленную документацию и рекомендации для разработчиков, чтобы эта атака не продолжалась. Бородин цитировался в различных веб-статьях, заявив, что "игра окончена" на основе обновленных API Apple и рекомендаций по лучшей практике.

Профилактика

В Apple есть целый документ, посвященный этой лазейке здесь. (EDIT: ссылка не работает, Wayback, если вы хотите... хотя документ охватывает iOS 5.1 и более ранние версии.) Самая большая точка, которую они поднимают что ваше приложение отправляет квитанцию на внешний сервер, который у вас есть, а затем ваш сервер проверяет получение с Apple. Однако, если вы отправляете квитанцию непосредственно из приложения в App Store, они рекомендуют следующие проверки:

Убедитесь, что сертификат SSL, используемый для подключения к серверу App Store, является сертификатом EV.
Убедитесь, что информация, возвращаемая из проверки, соответствует информации в объекте SKPayment.
Убедитесь, что квитанция имеет действительную подпись.
Убедитесь, что новые транзакции имеют уникальный идентификатор транзакции.

Поддельный сервер проверки

Если ваше приложение отправляет транзакционные квитанции на ваш сервер, а затем пересылает их в App Store, один из них - для злоумышленника, чтобы подделать ваш сервер проверки. Посредством какого-либо метода (изменение таблицы DNS, изменение URL-адреса и т.д.) Квитанция отправляется в другое место и возвращается "успешная проверка". Таким образом, квитанция никогда не достигает вашего сервера, и у вас никогда не будет возможности проверить ее с помощью App Store.

Комментарий

По-видимому, в магазине Cydia есть множество приложений, которые служат для работы в фоновом режиме, отслеживают трафик получения и перенаправляют его для этой цели. Источник: Блог Hussulinux

Профилактика

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

Поддельные квитанции

Злоумышленник может подделать процесс покупки, а затем отправить поддельную квитанцию на ваш сервер проверки. В отличие от предыдущей атаки, исходящее местоположение квитанции не изменяется, но оно заменяется самозванцем. Эта поддельная квитанция фактически является действительной квитанцией из предыдущей транзакции в App Store, и App Store проверяет ее как таковой. Подделывая процесс покупки, а затем отправляя поддельную квитанцию на ваш сервер, контент никогда не оплачивается.

Комментарий

По-видимому, существует множество приложений Cydia, которые делают такие вещи. Вы можете определить поддельные квитанции, потому что их product_id полностью отличается от всего, что вы используете в своем приложении. По-видимому, самым известным поддельным идентификатором является com.zeptolab.ctrbonus.superpower1. Источник: Блог Hussulinux.

Профилактика

В ссылке, где я нашел эту атаку, блоггер рекомендовал вам распаковать квитанцию на вашем сервере проверки (base64_decode) и проверить product_id перед отправкой квитанции в App Store. Однако в в этой статье Apple рекомендует сначала отправить квитанцию в App Store, а затем прочитать возвращенную информацию, чтобы убедиться, что квитанция действует.

(Кроме того, исправьте меня, если я ошибаюсь, но рекомендованная Apple методика также может использоваться для предотвращения такой атаки, даже если у вас нет сервера проверки. Если ваше приложение отправляет расписку непосредственно в App Store, он мог бы проверить содержимое ответа JSON, чтобы убедиться, что он действителен. Но это касается того, что Apple рекомендовала лучшие практики использования внешнего сервера проверки, поэтому я бы не стал защищать его.)

При закрытии

Это те атаки, о которых я знаю, не стесняйтесь исправлять меня, если я ошибаюсь в любой момент или предлагаю дополнительные атаки и исправления.

В качестве примечания, есть этот веб-сайт: http://www.in-appstore.com/, который утверждает, что разрешает покупки в приложении бесплатно, либо на iOS 5, либо на с взломанным iOS 6 устройством, и активен с 5 июля 2013 года. Хотя я не уверен на 100%, как они это делают, он определенно включает перенаправление DNS и поддельные сертификаты безопасности, что подразумевает Fake App Store или Fake Verification Server, который дополнительно подразумевает, что там все еще есть приложения, которые не защищены от этих атак.

Ресурсы

EDIT:

Дополнительные

Кажется, что сюда подошел один или два человека и нашел это сообщение полезным, и я рад.

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

http://www.se7ensins.com/forums/threads/tut-how-to-hack-ios-games-and-apps.701845/ http://www.iapphacks.com/

Пара немедленных вылетов: не храните данные вашего игрока в простом plist, если вы не хотите, чтобы его редактировали некоторые подростки. Люди не должны взломать вашу систему IAP, если они могут просто дать себе золото или что-то подобное, отредактировав файлы на диске. Возможно, зашифровав эти файлы, вы можете отбить определенный сегмент злоумышленников.

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

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