Добрый день.
Возник вопрос, касающийся защиты от несанкционированного доступа к контенту, получаемому мобильным приложением через API. Речь идет о платных подписках на медиа-контент (статьи, видео и проч.) в мобильном приложении БЕЗ регистрации (нет учетной записи, авторизации и проч. Только покупки подписки). Понятно, что нужно как минимум завернуть все в https. Понятно, что нужно проверять ID покупки через средства Google InApp Billing.
Да, можно защитить копирование текста из приложения, сохранения картинок и видео, можно даже скриншоты запретить. Но API остаются "голыми". Достаточно посмотреть куда ходит трафффик, с какими ключами и вытянуть все curl'ом. Была мысль зашивать ключ или сертификат в само приложение, но, насколько я понимаю, выковырять его оттуда на рутованном девайсе не составит большого труда.
Интересует вопрос: а как эта защита правильно реализуется? Ведь существует много подобных сервисов, и логично предположить, что этот вопрос там решен.
Это как раз понятно. Вопрос в том, как именно надо заморочиться, чтобы создать потенциальному злоумышленнику побольше геморроя? Понятно, что тут и фантазия, и "секретность алгоритмов" (прямое нарушение правила Керкхоффа), но толковое, рабочее и популярное что-нибудь есть?
на чтото толковое вы потратите очень много времени. Я постоянно работаю с API и ограничений видел тонны
- Ограниченный апи? возьмем тот что юзает приложение
- Нет апи? вытащим из приложения
- ограничение на размер запросов? сделаем 100500 запросов
- ограничение по времени запросов? будет выполнять их непрерывной очередью
итд
Понятно, что нужно как минимум завернуть все в https.
Вообще непонятно зачем тут https
Понятно, что нужно проверять ID покупки через средства Google InApp Billing.
Тоже непонятно зачем это.
Достаточно посмотреть куда ходит трафффик, с какими ключами и вытянуть все curl'ом.
Вообще непонятная фраза. Вытануть все можно только если вы это разрешаете.
Так как же защитить контент от слива через API?
Ну так проверяйте наличие оплаты перед доступом. Деньги пришли - отправили приложению ключ доступа к API. Оно может зайти и скачать.
Денег нет - никому ключ не отправляли, никто ничего скачать не может.
Шифруйте отдаваемый контент через RSA между сервером и приложением. (SSL/не SSL - это мы сейчас не рассматриваем!)
1. Формируйте УНИКАЛЬНЫЙ! контент/трафик для каждого пользователя и расшифровывайте доставленный контент исключительно в памяти приложения, непосредственно перед моментом отображения на экране!
2. Используйте платёжные данные при шифровании данных на сервере.
3. Меняйте ключ при каждом запросе на основе номера пакета текущей сессии, времени, случайного числа и т.д.
4. Отдавайте контент порциями с разным шифрованием - prefetch/segmentation.
5. Обновляйте протокол внутреннего шифрования хотя бы раз в 1-2 месяца.
Нет 100%-ой защиты на клиенте, которая не позволила бы сохранять контент.
За то - можно это усложнить до нереальных трудозатрат.
А разве защиты по ID покупки недостаточно?
curl'ом не получится вытащить больше, чем было куплено.
Если не хотите чтобы купленное можно было вытащить еще как-то, кроме как в самой аппке, попробуйте впилить once-token'ы, генерацию которого будет знать только ваша апка.
Это позволит сделать так, чтобы все запросы были валидными только единожды.
Конечно, остается кейс, когда запрос до сервера "не доходит", а потом исполняется curl'ом, но это уже из разряда паранойи.
Сложность защиты должна быть соизмерима с ценностью защищаемого контента.
Любая подобная защита это защита от дурака. Если апка может генерировать временный токен, то что угодно сможет. Вытащить алгоритм это не сложная задача и чисто вопрос времени, после чего защиты буд-то и нет.
Помимо прочего, насколько я понимаю, мы вытягиваем данные один раз - при покупке. Но речь идет о подписке, контент появляется много раз за месяц, а покупка только один раз в месяц.
Дайте клиенту токен - ничего не значащий guid, пусть его предъявит API, получит следующую порцию контента, смените токен через период N (минута, час, день, неделя).
Liudar, ничего не мешает. Более того, за исключением одоразовых шифр-блокнотов, все остальные методы потенциально уязвимы.
Методы аутентификации надо включать в сам API, чтобы на вход любому открытому методу подсовывалось что-то удостоверяющее вызывающую сущность.
Здесь только один способ - экранировать запросы через собственный сервер, откуда уже и отправлять запросы к платному API
Мобильное приложение -> свой сервер -> платный API
Средний
Простой
Средний
Простой
Средний
