В предыдущей частимы обсуждали небезопасные внешние и внутренние хранилища и небезопасное общение.
Атака через контент-провайдера:
Мы рекомендуем изучить , прежде чем начать, что является полезным в случаях, когда приложение хочет обмениваться данными с другим приложением.
Экземпляр контент-провайдера управляет доступом к структурированному набору данных, обрабатывая запросы от других приложений. Все формы доступа в конечном итоге вызывают контент-провайдера, который затем использует конкретный метод контент-провайдера для получения доступа.
Требуемые методы
Query (), Insert (), Update (), Delete (), Get Type (), On Create ()
Т.к. эти методы являются такими же, как база данных, прежде всего, мы должны проверить инъекции через URI.
Чтобы проверить инъекции, мы можем использовать инструменты drozer.
Код:
Запустите scanner.provider.finduris –a
Код:
Запустите scanner.provider.injection -a
Content query –Uri
Смягчение – Android
Если ваш контент-провайдер предназначен только для использования вашего приложения, установите его как android: exported = false в манифесте. Если вы намеренно экспортируете контент-провайдер, вы также должны указать один или несколько разрешений для чтения и записи.
Если вы используете контент-провайдер для обмена данными между вашими собственными приложениями, предпочтительнее использовать android: атрибут уровня защиты, установленный для защиты «подписи».
При доступе к контенту-провайдеру используйте параметризованные методы запроса, такие как query (), update () и delete (), чтобы избежать потенциальной SQL инъекции из ненадежных источников.
Небезопасная (слабая) криптография:
Защита конфиденциальных данных криптографией стала ключевой частью большинства веб-приложений. Простое шифрование конфиденциальных данных очень распространено. Приложения, которые шифруют часто, содержат плохо разработанную криптографию, либо используя несоответствующие шифры, либо делая серьезные ошибки с использованием сильных шифров. Эти недостатки могут привести к раскрытию конфиденциальных данных и нарушению соблюдения правил безопасности.
Декодирование base 64 – декодирование имени пользователя
Мы получаем код от обратной разработки – алгоритм использования аутентификации.
Взлом пароля при помощи AES-Exploit
Смягчение:
Не используйте слабые алгоритмы, такие как MD5 / SHA1. Используйте более безопасные альтернативы, такие как SHA-256 или что-то лучшее.
Генерируйте ключи в автономном режиме и храните конфиденциальные ключи с особой осторожностью. Никогда не передавайте личные ключи по небезопасным каналам.
Убедитесь, что учетные данные инфраструктуры, такие как базы данных или сведения о доступе к очереди MQ, должным образом защищены (через жесткие разрешения и средства файловой системы) или надежно зашифрованы, таким образом, чтобы их было сложно дешифровать локальным или удаленным пользователям.
Убедитесь, что зашифрованные данные, которые хранятся на диске, нелегко расшифровать. Например, шифрование базы данных бесполезно, если пул соединений с базой данных обеспечивает незашифрованный доступ.
Жестко закодированный пароль в исходном коде:
Жестко закодированные пароли могут поставить под угрозу безопасность системы таким образом, который может доставить немало проблем и не сможет быть с лёгкостью устранен.
Никогда не рекомендуется жестко кодировать пароль. Мало того, что жесткое кодирование пароля позволяет всем разработчикам проекта просматривать пароль, это также затрудняет устранение проблемы.
Если код уже находится в процессе производства, пароль не может быть изменен без исправления программного обеспечения. Если учетная запись, защищенная паролем, взломана, владельцы системы будут вынуждены выбирать между безопасностью и доступностью.
