Почему важно устанавливать полезную нагрузку разработчика с помощью биллинга в приложении?

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

Из "Рекомендации по безопасности" :

Задайте строку полезной нагрузки разработчика при совершении запросов на покупку

С API-интерфейсом для биллинга версии приложения 3 можно добавить разработчика при загрузке запроса на поставку в Google Играть. Как правило, это используется для передачи в токенах строк, которые однозначно идентифицирует этот запрос на покупку. Если вы укажете строковое значение, Google Play возвращает эту строку вместе с ответом на покупку. Впоследствии, когда вы делаете запросы об этой покупке, Google Play возвращает эту строку вместе с деталями покупки.

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

Когда вы вернетесь в ответ от Google Play, убедитесь, что вы подтвердили что строка полезной нагрузки разработчика соответствует маркеру, который вы отправили ранее с запросом на покупку. В качестве дополнительной безопасности предосторожности, вы должны выполнить проверку самостоятельно сервер.

Правильно или неправильно, я решил не принимать "дополнительную меру безопасности" для настройки сервера для проверки покупки. И я не храню свою собственную запись о покупке - я всегда называю API биллинга. Так действительно ли есть какая-то причина для моей проверки данных? Сам API проверки проверяет подлинность пользователя перед сообщением купленного предмета, а если злоумышленник скомпрометировал устройство (приложение или API игры google), я не вижу никакой пользы от дополнительной проверки на пользователь идентифицирует устройство, где его можно легко обойти. Или есть причина для этого, о чем я не думаю?

Ответ 1

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

Лично я считаю, что вся эта часть "лучших практик" запутывает и пытается заставить вас работать, что API действительно должен делать. Поскольку покупка привязана к учетной записи Google, и Play Store, очевидно, сохраняет эту информацию, они должны просто дать вам это в деталях покупки. Получение правильного идентификатора пользователя требует дополнительных разрешений, которые вам не нужно добавлять, чтобы покрыть недостатки IAB API.

Итак, короче говоря, если у вас нет собственного сервера и специальной логики надстройки, просто не используйте полезную нагрузку разработчика. Вы должны быть в порядке, если работает IAB v3 API (что, к сожалению, довольно большое, если "на данный момент" ).

Ответ 2

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

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

например.

Предположим, что наше приложение имеет логин для userA и userB. А Android-аккаунт Google Android - X.

userA, входит в наше приложение и покупает членство в жизни. Сведения о покупке хранятся в учетной записи Google X.
userA выходит из системы, а userB регистрируется в нашем приложении. Теперь userB также получает выгоду от членства в жизни, поскольку андроидная учетная запись google по-прежнему X.

Чтобы избежать такого злоупотребления, мы свяжем покупку с учетной записью. В приведенном выше примере мы будем устанавливать полезную нагрузку разработчика как "userA", когда пользовательA совершает покупку. Поэтому, когда пользователь вводит код, полезная нагрузка не будет соответствовать подписанному пользователю (userB), и мы проигнорируем покупку. Таким образом, пользовательский B не может получить выгоды от покупки, сделанной пользователем.

Ответ 3

Существует также другой подход к обработке полезной нагрузки разработчика. Поскольку Николай Еленков сказал, что слишком много накладных расходов, чтобы требовать идентификатор пользователя и устанавливать дополнительные разрешения для профиля пользователя для вашего приложения, так что это не очень хороший подход. Поэтому давайте посмотрим, что Google говорит в последней версии примера примера TrivialDrive в примерах In-App Billing v3:

ПРЕДУПРЕЖДЕНИЕ: локальная генерация случайной строки при запуске покупки и проверка его здесь может показаться хорошим подходом, но это не удастся в случай, когда пользователь покупает товар на одном устройстве, а затем использует ваше приложение другое устройство, поскольку на другом устройстве у вас не будет доступа к случайную строку, которую вы изначально создали.

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

Ответ 4

Это зависит от того, как вы проверите developerPayload. Существует два сценария: дистанционная проверка (с использованием сервера) и локальная (на устройстве).

Сервер

Если вы используете сервер для проверки developerPayload, это может быть произвольная строка, которую можно легко вычислить как на устройстве, так и на сервере. Вы должны иметь возможность идентифицировать пользователя, выполнившего запрос. Предполагая, что каждый пользователь имеет соответствующий accountId, developerPayload может быть вычислен как комбинация с purchaseId (название SKU) следующим образом:

MD5(purchaseId + accountId)

Устройство

developerPayload не должен быть электронной почтой пользователя. Хорошим примером того, почему вы не должны использовать электронную почту в качестве полезной нагрузки, является служба Google for Work. Пользователи могут изменять свою электронную почту, связанную с учетной записью. Единственная постоянная вещь - accountId. В большинстве случаев электронная почта будет в порядке (например, адреса Gmail неизменяемы в данный момент), но не забудьте создать для будущего.

Несколько пользователей могут использовать одно и то же устройство, чтобы вы могли отличить, кто является владельцем этого элемента. Для проверки устройства developerPayload - это строка, которая однозначно идентифицирует пользователя, например:

MD5(purchaseId + accountId)

Заключение

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

Полезная нагрузка не обеспечивает безопасность. Его можно легко подделать под "устройство" и без каких-либо усилий использовать в проверке "сервер". Не забудьте выполнить проверку подписи с помощью открытого ключа, доступного в консоли учетной записи Google Publisher.

* A обязательно прочитать сообщение в блоге об использовании идентификатора учетной записи вместо электронной почты.

Ответ 5

В видеоролике Google IO о IAB v3, предоставленном автором тривиального примера диска, это было кратко адресовано к концу видео. Это предотвращает повторные атаки, например. злоумышленник обнюхивает трафик, крадет пакет, содержащий успешную покупку, а затем пытается воспроизвести пакет на своем собственном устройстве. Если ваше приложение не проверяет личность покупателя через полезную нагрузку dev (идеально на вашем сервере), прежде чем выпускать премиальный контент (также идеально с вашего сервера), злоумышленник добьется успеха. Проверка подписи не может обнаружить это, поскольку пакет не поврежден.

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

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

Ответ 6

Я боролся с этим. Поскольку учетная запись Google Play может принадлежать только одному из "управляемых" элементов, но может иметь несколько устройств (у меня их три), вышеупомянутый комментарий от кого-то, что вы продаете "на устройство", не будет работать... они быть в состоянии поставить его на свое первое устройство, а другие нет... Если вы покупаете премиум-апгрейд, он должен работать на всех ваших телефонах/планшетах.

Я презираю понятие получения адреса электронной почты пользователя, но я действительно не нашел другого надежного метода. Таким образом, я беру 1-ю учетную запись, которая соответствует "google.com" в списке учетных записей (да, разрешение на добавление в ваш манифест), а затем сразу же хеш файл, поэтому он больше не может использоваться в качестве адреса электронной почты, но обеспечивает "достаточно уникальный" "токен. Это то, что я отправляю в качестве полезной нагрузки для разработчиков. Поскольку большинство людей активируют свое устройство с помощью своего идентификатора Google Play, есть хороший шанс, что все три устройства получат один и тот же токен (используя один и тот же алгоритм хеширования на каждом устройстве).

Он даже работает на KitKat с несколькими "пользователями". (Мой идентификатор разработчика находится на одном пользователе, мой идентификатор теста на другом и каждый пользователь в своей песочнице).

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

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

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

Ответ 7

Это часто реагирует на определение продукта (ваше приложение). Например, для случая подписки. Будет ли тот же пользователь использовать подписку на всех устройствах, которые у него есть? Если да, то да. Мы не проверяли полезную нагрузку.

Для расходных материалов. Предположим, что покупка в вашем приложении дает вам 10 виртуальных монет. Смогут ли пользователи использовать эти монеты на разных устройствах? 4 на одном устройстве и 6 на другом? Если мы хотим работать только на устройстве, которое совершило покупку, мы должны проверить полезную нагрузку, например, с помощью самогенерируемой строки и локально сохраненной.

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

Привет

Сантьяго