Что нужно изменить в модуле BillingService для повышения безопасности?

Комментарий для класса BillingService рекомендует:

Вы должны изменить и запутать этот код перед его использованием.

Хорошо, но что нужно изменить?

Название класса? TAG используется для регистрации? Имена методов и члены данных? Логика и сам поток программы? Другой?

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

Источник

3 ответа

Решение

Я работаю над этим в данный момент, и мой подход пока таков:

  1. Я использую BillingReceiver, Billing Service, PurchaseObserver и ResponseHandler.
  2. Я переместил все константы в свой собственный класс констант, и все вышеперечисленные классы включены в мой собственный пакет.
  3. Я покончил с классом PurchaseDatabase и интегрировал его части в свою собственную базу данных SQLite, DBAdapter и классы доступа к данным.
  4. Я изменил CatalogEntry на свой собственный объект модели, и мой пользовательский интерфейс будет сильно отличаться от примера, например, группа RadioButton, а не Spinner для элементов продукта (у меня только 4).
  5. В классе Security говорится: "Для безопасной реализации весь этот код должен быть реализован на сервере, который взаимодействует с приложением". Мне "повезло", что мое приложение все равно должно связаться с моим сервером, поэтому я буду применять эти меры безопасности на сервере и самостоятельно проверять информацию о покупке, переданную на сервер. Я пытаюсь защитить эту часть связи с помощью SSL, и мне уже требуется предварительное имя пользователя / пароль (хешированные и соленые), которые хранятся на моем сервере.
  6. Я вырезал любой другой лишний код, который я не использую, например, редактирование полезной нагрузки.
  7. Некоторые из методов имеют 5 или 6 параметров в своей подписи, например, onPurchasestateChanged() - я думал о том, чтобы объединить их в один объект-обертку (но пока не сделал этого).
  8. Я тестирую это медленно и тщательно, чтобы понять, что происходит, и следую рекомендациям. Сначала я использовал полный образец, чтобы убедиться, что он работает, и проверил статические ответы. Затем я начал вносить свои собственные изменения, все еще проводя статическое тестирование. Я все еще тестирую со статическими ответами, и я буду следить за потоком сообщений, чтобы понять происходящие обмены. Как только я буду доволен этим, я протестирую свои собственные идентификаторы продуктов и постараюсь убедиться в своих данных и их безопасности.
  9. Я думал, что строка developerPayload также может быть подписана и зашифрована, а когда возвращена на мой сервер, расшифрована и проверена на целостность.
  10. Наконец, я запутываю код с помощью ProGuard и следую некоторым советам, которые доступны в Stackru.

Надеюсь это поможет.

Источник

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

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

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

Источник

Они объясняют это следующим образом:

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

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

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

По сути, я не думаю, что они имели в виду сам billingService, а то, как вы используете его в своем приложении.

Источник
Другие вопросы по тегам