Безопасность мобильного приложения: Как защитить Android приложение от реверс инжиниринга
Вопрос защиты мобильного приложения всегда был актуален для разработчиков. Безопасность продукта — существенная составляющая его качества. И несмотря на быстро развивающийся рынок мобильных приложений, уровень пиратства откровенно расстраивает, особенно что касается андроида.
К сожалению, приложения являются достаточно легкой добычей: их легко взломать, отключить всю рекламу и даже отвязать от сервисов верификации. То есть вы, прилагая значительные усилия для создания хорошего приложения и надеясь получить с него прибыль, в итоге можете не только не достигнуть успеха, но и в какой-то мере “потерять” продукт.
Также кто-то может пожелать взломать его (устройство, программу, ПО) с целью понять принцип его работы и перенять идеи, а то и полностью воспроизвести приложение. Эта практика называется реверс инжиниринг (или обратный инжиниринг) и используется во многих сферах, включая электронику и даже военную промышленность.
Применительно к Android реверс инжиниринг представляет собой процесс извлечения исходного кода и ресурсов из APK файла. APK целевого приложения может быть изъят из телефона путем использования ADB или скачивания из Google Play Market.
ПРОБЛЕМА:
Декомпиляция APK файла не является сложной задачей. Через декомпиляцию APK и преобразование dex файлов в jar файлы и затем в исходный код java можно получить исходный код приложения. И тут вам помогут такие инструменты как dex2jar, jd-gui и JAD.
Как бы то ни было, полностью защитить приложение от реверс инжиниринга и обеспечить полную безопасность мобильного приложения практически невозможно.
Тем не менее вы можете максимально усложнить процесс взлома. В этой статье мы поделимся нашим практическим опытом в защите Android приложений от реверс инжиниринга.
НАШ ОПЫТ:
1. Использование ProGuard
Для защиты Android приложения от реверс инжиниринга мы используем инструмент ProGuard, предназначенный для сокращения, оптимизации и обфускации кода. Он работает следующим образом:
— обнаружение и удаление неиспользуемых классов, полей, методов и атрибутов;
— анализ и оптимизация байт-код методов;
— переименование остальных классов, полей и методов с использованием коротких бессмысленных имен.
Данные действия уменьшают базу кода, делая ее более эффективной и в то же время сложной для расшифровки. На заключительном этапе предварительной верификации добавляется информация в классы, необходимые для Java Micro Edition, Java 6 и т.д.
Стоит отметить, что обфускацию можно отменить с помощью деобфускатора, где APK De-Guard является одним из самых точных инструментов, поскольку он использует машинное обучение для получения наилучших результатов.
2. Перемещение важных частей кода на сервер
Говоря о других эффективных способах, мы также перемещаем наиболее важные части сервиса из приложения в веб-сервис, скрытый на стороне сервера.
Представьте, что у вас есть уникальный алгоритм. Само собой, вы не хотите, чтобы его у вас украли. Поэтому вы можете переместить его, сделав так, чтобы он обрабатывал данные на удаленном сервере и использовал приложение для его обеспечения этими данными.
3. Написание важного кода на C/C++
Мы иногда применяем NDK для написания алгоритмов изначально в .so файлы, которые намного реже декомпилируются по сравнению с APK. Кроме того мы используем SSL при взаимодействии между устройством и сервером.
Хотя он может быть разобран в assembly код, процесс реверс инжиниринга большой библиотеки из assembly довольно трудоемкий. По сравнению с C / C ++, Java легче декомпилировать.
4. Использование SSL
При взаимодействии устройства и сервера используйте SSL. В некоторых случаях вам может понадобиться ваш сертификат. И класс, реализующий X509TrustManager или SSLSocketFactory интерфейс, может содержать тривиальные методы.
Это может привести к потере конфиденциальности данных, которые передаются протоколом SSL / TSL. Часто методы данного класса являются тривиальными, что делает приложение уязвимым для MitM атак.
Предоставив действительный самозаверенный сертификат, злоумышленник может нарушить конфиденциальность соединения и получить доступ к ценным данным. Даже если методы переопределенного класса не являются тривиальными, скорее всего их реализация будет иметь ошибки, приводящие к тем же последствиям.
К сожалению, это широко распространенное явление. Наши исследования показали, что около 40% мобильных приложений имеют неправильную реализацию этого класса.
Следуйте нашим рекомендациям для решения следующих SSL проблем:
— Проверяйте действительность сертификата каждый раз, когда устанавливается соединение через SSL / TLS протокол.
— Используйте реализации стандартов X509TrustManager.
— Если необходимо принять самозаверенный сертификат, создайте собственную реализацию X509TrustManager с помощью KeyStore. Также укажите сертификаты, которые должны быть приняты, и отклоните все остальные.
5. Не храните значения в необработанном формате
Далее, для хранения значений на устройстве мы не используем необработанный формат. Если нам нужно сохранить баланс пользователя (количество валюты приложения) или другие значения, мы обычно сохраняем закодированные значения (например, храним их в форме какого-либо алгоритма).
6. Учетные данные пользователя
Еще одна наша рекомендация относится к данным учетной записи пользователя.
— Во-первых, следует свести к минимуму частоту запросов учетных данных пользователя в приложении. Это позволит вам сделать фишинговые атаки более заметными и снизит вероятность их успеха. В этом случае мы советуем использовать токен авторизации (также не забудьте обновить его).
— Во-вторых, имя и пароль не должны храниться на устройстве (когда это возможно). Мы советуем выполнять процесс авторизации с помощью имени и пароля и использовать маркер авторизации.
Если вам нужно предоставить пользователям возможность хранить их учетные данные для автоматизации будущей авторизации в приложении, используйте объект Credential, содержащий информацию о регистрации пользователя.
7. API ключи
Обычно сторонние поставщики используют API ключ как удобный механизм проверки подлинности пользователя для предоставления доступа, а также как способ взимания платы за свои данные.
Также не следует хранить ключи в общих настройках или папках, так как злоумышленник может легко распаковать и декомпилировать ваш APK файл и получить этот ключ. Для сохранения ключа используйте обмен ключами NDK или Private / Public API.
8. Алгоритмы хэширования
MD2, MD5, SHA1 хэш-функции имеют некоторые уязвимости. Если они используются для хранения ценной информации (например, паролей), ее конфиденциальность может быть нарушена. Используйте безопасные хэш-функции (SHA-2).
Хеш-функция, используемая для хранения паролей, должна быть не только устойчивой, но также не должна быть слишком быстрой. Это усложняет атаку путем исчерпывающего поиска. Для этого были разработаны такие специализированные хеш-функции как PBKDF2, bcrypt, scrypt.
9. Небезопасное использование отражения
Можно выполнить произвольный вредоносный код. Метод, реализующий отражение, берет данные из ненадежного источника в качестве аргумента. Он позволяет злоумышленникам управлять графиком потока управления приложениями, а также обходить механизмы аутентификации и ограничения доступа.
Наши рекомендации:
— Создайте белый список допустимых команд и сделайте пользователям возможность выбирать их только из этого списка. Не используйте введенные пользователем данные непосредственно в качестве аргумента методов, реализующих отражение.
— Если отражение используется в сочетании с файлами конфигурации, убедитесь в целостности и уникальности этих файлов. Не устанавливайте параметры отражения в файлах конфигурации при отсутствии значительных ресурсов для анализа безопасности решения.
10. Использование внешнего хранилища
Файлы, записанные на внешнее запоминающее устройство, читаются всеми приложениями и могут быть изменены, когда пользователь подключает устройство к компьютеру в режиме USB-накопителя.
Кроме того, файлы, хранящиеся во внешнем хранилище, останутся там даже после удаления приложения. Это может привести к потере конфиденциальных данных. Вот почему мы храним файлы во внутренней памяти или используем базу данных SQLite.
Как бы то ни было, полностью защитить приложение от реверс инжиниринга мобильного приложения практически невозможно.
Тем не менее, перечисленные способы позволяют нам максимально обезопасить Android приложения. Мы советуем вам использовать их для защиты своих мобильных приложений от взлома и обеспечения более высокого уровня безопасности.
Если вы — специалист в Android разработке, предлагаем вам ознакомиться с нашей вакансией. Мы будем рады предоставить вам конкурентную оплату труда, профессиональный рост и работу над интересными проектами. Ждем ваше резюме.) (Добавлено 18.06.2018)