Занимаюсь реализацией API для своих приложений на Android / iOS. В API есть возможность покупки товаров и я уверен, что найдутся "умники" которые отловят запросы передаваемые. А дальше могут быть плохие последствия.
Были несколько вариантов защиты:
1. client_id & client_secret по типу oAuth 2.0 . Но этот принцип самый банальный. Я просто передаю открыто доступ злоумышленнику и он спокойно может используя client_id и client_secret использовать API.
2. Была задумка реализации, где при авторизации пользователя в приложении отправлялся запрос на сервер. Далее выдавался ключ который я генерирую и храню в БД. И при важных запросах (покупка, редактирование профиля) используя этот ключ, приложение криптовало JSON параметры в AES256 используя этот ключ. И отправлял данные на сервер. Но ведь можно изначально отравив ключ, узнать что хранится в отправляемом запросе.
В общем, вариантов куча. Но очень слабые! Посоветуйте что-нибудь стоящее. Спасибо заранее.
А кого вы опасаетесь? Что купит владелец приложения, а использует левый человек?
Или у вас вообще никак не отслеживается, что владелец приложения купил?
abcyu: мое приложение похоже на приложение товаров. И представьте, что человек переходит к оплате яндекс или другой системы. Далее он отправляет какие товары купил на API и сколько. Оплатить то, он оплатит 1 кг. картошки (например), а на апи подменит 10кг. В итоге, в заказах панели управления на апи, будет 10кг.
а почему это КЛИЕНТ САМ после оплаты отправляет какие товары купил и сколько?
Обычно это делают так:
Клиент сообщает вашему серверу, что хочет купить пачку макарон и килограмм картошки.
Сервер запоминает это как "Заказ № 1234566435345".
Клиент перенаправляется на платежную систему для оплаты именно "Заказа № 1234566435345".
Платежная система (а не ваш клиент) сообщает вашему серверу, что "Заказ № 1234566435345" оплачен.
Ваш сервер отдает клиенту товары по списку товара из "Заказа № 1234566435345"
Ingush Archakov: А отношения между платежной системой и вашим сервером априори защищены (см. описание API платежного сервера), там предусмотрено, чтобы номер заказа нельзя было подменить.
Товар же подменить нельзя, потому что он хранится у вас.
Да даже пусть сделано так как Вы сказали.
Клиент после покупки сообщает серверу что купил.
Ну а кто вам мешает проверять сумму и сверять с платежной системой?
Какая разница вам если он оплатил 1 кг картошки и 0,1 кг икры, а забрать хочет 10 кг картошки и 0 кг икры, если итоговая сумма не превышает.
Сергей Протько: Так можно совмещать, подпись делается очень просто, накладные расходы на ее использование ничтожно малы, не вижу причин ее не добавлять.
JWT для аунтентификации, человеку же надо покупки товаров защитить. И тут интересная штука, ибо защита вся сводится к тому что бы запрашивать подтверждение платежа.
А вообще, довольно странный кейс.
Если кто-то сильно захочет перехватить данные - он это сделает, а простейшая защита от "типахакеров" - https. Ну и на бакэнде, само собой, нужно проверять транзакции.
Средний
Простой
Средний
