Сливают баланс на SMS-гейте (авторизация в мобильном приложении), как защитить?

Question

[z0rgoyok]

Есть скрипт вроде client.php?action=get_code&phone=телефон.
Кто-то додумался подставлять туда номера и получать коды, соответственно баланс очень быстро уменьшается. Как защитить?

Answer 1

[Дмитрий Скогорев]

капча
токены

Comments

[z0rgoyok]

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

[Дмитрий Скогорев]

@z0rgoyok ну так вы бы написали что это мобильное приложение. слать смс по авторизации. если число смс для аккаунта более 5 в час - блокировать на час

[_ _]

@z0rgoyok только вот сложность разная.
Одно дело сливать баланс, дергая никак не прикрытую ссылку, другое дело - необходимость доставать токен путем декомпиляции.
Можно ограничивать количество запросов с одного IP-адреса, но в этом случае могут долбить проксями.

[z0rgoyok]

ссылку очевидно выдернули из java приложения, так же выдерут и другую. нужно что-то принципиальное, пока вижу только включение капчи при большом количестве запросов. @EnterSandman @AMar4enko

[_ _]

@z0rgoyok может вы просто забыли обфускацию сделать? ProGuard, если про андроид речь. Ну и напоследок - у вас же все через HTTPS ходит, да?

[z0rgoyok]

ProGuard да, забыли. а https как решит проблему? придумал такое: на клиенте и на сервере считать хэш от user-agent'а например и все это шифровать ProGuard. сработает?

[_ _]

@z0rgoyok без HTTPS весь ваш трафик на виду. На локальную машину ставится DNS-сервер, в WiFi подключении на трубе в качества DNS-сервера указывается адрес локальной машины. После этого можно проксировать весь трафик на оригинальный сервер и WireShark'ом видеть весь обмен данными. Это даже проще, чем декомпиляция. HTTPS защитит вас от этого простейшего MiM.
Думаю, что токена, обфускации кода подсистемы общения с сервером и HTTPS будет достаточно, чтобы отбить охоту лезть в ваше приложение у 99% кулхацкеров. Оставшийся 1% будет слишком дорог, чтобы такие мелкие пакости творить.

[Дмитрий Скогорев]

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

[z0rgoyok]

Спасибо, прикрутим все сразу и капчу для самых тяжелых случаев :)

[Дмитрий Скогорев]

@z0rgoyok на самом деле @AMar4enko дело говорит. HTTPS сертификатом на клиенте и проверкой его на стороне сервера. Тут MITM будет сложно провести

[_ _]

@EnterSandman тут извечный вопрос, как сохранить секретный в мобильном приложении так, чтобы он не достался врагу, ну и в целом предотвратить депомпиляцию кода. Нет смысла в изощренных алгоритмах, если они будут после декомпиляции как на ладони.

[z0rgoyok]

Ну неужели можно положить регистрацию какого-нибудь Whatsapp такими методами?

[Дмитрий Скогорев]

@AMar4enko а вот тут косяк приложений на адроиде. яблочные/блекбери или симбиан приложения не разбираются. Андроид и ВинФон - на ура

[z0rgoyok]

@EnterSandman разбираются яблочные при желании (снимается дамп, а дальше декомпилируется как обычно)

[Дмитрий Скогорев]

@z0rgoyok масштаб другой. и там если человек раза 3 попробует послать себе смс для регистрации - его на какое-то время забанят. всё честно. другое дело - запрашивать много регистраций - тут можно и нужно отслеживать udid или другой параметр. ну а если уж всё вместе начнут перебирать - только по IP

[Дмитрий Скогорев]

@z0rgoyok дайте линк где можно почитать

[z0rgoyok]

@EnterSandman reverseengineering.stackexchange.com/questions/159...

Answer 2

[Spin7ion]

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