Варианты защиты приложения от хакеров

После того как ваше приложение попадет в App Store или Google Play и получит хоть какую-либо огласку, то оно непременно будет атаковано хакерами или просто любопытными программистами. Причин тому может быть множество — это могут быть конкуренты, просто недоброжелатели, заинтересованные в новых технологиях инженеры или просто «коллеги по цеху».

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

Так же приложение и связанные с ним сервисы могут являться источником данных (data-mining’a) для других сервисов, например, если вы через API выгружаете ценные справочники или каталоги для своей программы.

Способов защитится от этого существует несколько, попробуем разобрать несколько из них.

Защита протокола

Во-первых, не стоит боятся использовать нестандартные протоколы и собственные алгоритмы шифрования и обфускации. Запомните — чем более распространенный вы используете способ защиты, тем быстрее злоумышленник подберет «отмычку» к вашему сервису.

Вариантов сделать протокол особенным и неузнаваемым существует множество:

• Создание дополнительной абстракции (туннеля) поверх стандартного HTTP протокола
• Шифрование тела запроса с помощью ключа, который меняется с каждым вызовом
• Лимитирование запросов по времени или API-ключу

Правильная архитектура протокола

Важно не просто предотвратить неправильную эксплуатацию API, но так же не позволить через дырки в архитектуре допустить утечку чужих данных.

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

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

HTTPS или просто HTTP

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

В незащищенный HTTP стоит выносить разве что CDN-запросы к статическому контенту, но при этом стоит следить за тем, чтобы из их URL запроса нельзя было вытащить персональные данные, например, ID пользователя.

Шифрование БД

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

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

Как НЕ стоит защищать программу

Ниже перечислены несколько плохих практик, которые часто встречаются среди разработчиков приложений:

• Использование нестандартного порта (80, 443, …), для того чтобы «спрятать» соединения с сервером, создаст проблемы в закрытых (корпоративных) ID никак не транслирует биометрию пользователя обратно в программу и не генерирует пароли на её основе, а лишь говорит ДА/НЕТ по результату проверки отпечатков пальцев. Такая проверка легко обходится через отладчик программ или просто через jailbreak.