Какие 10 угроз безопасности применяются к приложениям для Android?

Question

Я знаю, что этот вопрос может быть кажется немного вредоносным в природе, но я просто пытаюсь изучить лучшие практики разработки Android/мобильных приложений, а безопасность, безусловно, большая проблема в программном обеспечении. Если вы все еще, прочитав этот вопрос (!), Подумайте, что это злонамерен в природе, просто имейте в виду, я не прошу , как для реализации любой из этих атак, я просто прошу , который атакует хороший Android/мобильный разработчик должен быть осведомлен.

Ниже приведен список «официальных» OWASP Топ-10 угроз безопасности для приложений (ссылка here). Мне было интересно, какие из них (если таковые имеются) применяются к разработке Android, или если есть какие-либо другие крупные нападения не перечислены здесь:

• Injection
• Cross-Site Scripting (XSS)
• Разбитое аутентификации и Управление сеансов
• небезопасная Direct Object Ссылка
• Request Cross-Site Подделки (CSRF)
• безопасность расконфигурация
• Insecu повторно Cryptographic хранения
• Невыполнение Ограничить URL Access
• Недостаточный Transport Layer Protection
• непроверенных Перенаправления и нападающие

Пожалуйста, обратите внимание: я не говорю о веб-сайтах, которые построены для отображается в мобильных устройствах , Я говорю о реальных приложениях, которые развертываются на мобильных устройствах. В случае Android это означает APK s.

Answer 1

Это трудно ответить на ваш вопрос, потому что от специфики того, что Вы отправили вам интересно о вашем Android приложений и вашего сервера Java, но вы спрашиваете, очень общий вопрос. Большая часть того, что публикует OWASP, очень высока, поэтому получение каких-либо реальных существенных ответов будет трудно, не зная о специфике работы вашего приложения и сервера Android. Как правило, люди не собираются атаковать телефон, когда могут идти за сервером, и владеют всеми данными, которые будут проходить через все телефоны, а не только один телефон.

Так что инъекции, XSS, CSRF и т. Д. В основном применяются к серверной стороне.Вы можете выполнить инъекцию в базу данных Android SQLite, если ваша программа использует ее (см., Как здесь описываются особенности вашего приложения). XSS, CSRF может применяться, если приложение является веб-клиентом или использует веб-просмотр для любой его части (опять-таки специфика вопроса).

Впрыск на сервер для Java можно легко исправить, используя PreparedStatements/PreparedCall. Не используйте Statement. Если вы используете JPA, Hibernate, iBatis, большинство из них используют PreparedStatements под капотом. Инъекция в Java-приложения легко расстроить эти атаки:

https://www.owasp.org/index.php/Preventing_SQL_Injection_in_Java

XSS и CSRF сложнее, но можно предотвратить с помощью фильтра. Прочитайте эту страницу, и вы увидите, где есть другая ссылка на проект, который ее описывает.

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

Отправка паролей через незащищенное соединение. Если вы отправляете пароль через HTTP или не-SSL-сокет, тогда вы будете раскрывать слишком много информации (использование односторонних хэшей не помогает, потому что мне не нужно знать пароль. Мне нужен только хэш и это передается в ясности). Поэтому убедитесь, что вы используете SSL для аутентификации пользователей. Затем мы можем понять, как вы храните эти пароли в своей базе данных. Вы используете односторонний хеш? Вы используете bcrypt? Если вы не используете ОСВ? Вы повторяете хэш, чтобы увеличить время, необходимое для разрыва этого хэша?

Большинство взломов включает в себя получение доступа к базовой базе данных через вульны в ОС, базу данных, SQL-инъекцию и т. Д. Захват таблицы, хранящей пользователя и пароли. Затем выполните супер быстрый метод грубой силы, используя простые с полки графические карты для перебора паролей. Большинство односторонних хэшей могут быть нарушены сегодня, используя этот метод, если вы не берете на себя надлежащую защиту своих паролей.

Answer 2

Для приложений (Android) большинство упомянутых атак не применяются регулярно.

Если вы заботитесь, чтобы сообщить нам знать, кто, в вашем случае, Alice, Bob, or Eve кто-то может дать реальный ответ на ваш вопрос, так:

• Кто должен быть защищен?
• Кому (хотелось бы) атаковать безопасность вашего приложения?

Самые реальная угроза, я могу придумать спонтанно (за недостаток информации я полагаю, довольно много автономного приложения на устройстве) будет ошибка в вашем приложении, которые либо

• утечка (app-) личная информация в незащищенном хранилище, или
• разрешает инъекции вредоносных данных через пользовательский ввод (чтение: SQL-инъекция, но общая проблема связана не только с SQL-базами данных, например, XML-инъекция ").

Edit:

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

• App пользователей: Есть ли у него, его данные, его денежные ценности , или его конфиденциальность должна быть защищена/поддерживаться приложением?

• Участник приложения: Является ли он угрозой для любого актива приложения и/или разработчика?

• Разработчик приложения: Должен ли он или его IP или другие активы, связанные с приложением, быть особо защищены дизайном приложения?

• Разработчик приложения: Может ли он или его окружающая среда представлять угрозу для любых активов, не принадлежащих ему?

• Сторонняя сторона: Существует ли какая-либо третья сторона, чей IP или другие значения необходимо защитить?

• Сторонняя сторона: Есть ли третья сторона, которая может быть заинтересована в компрометации безопасности для любого из вышеуказанных активов, возможно, унаследовать угрозу?

(добавить больше, если хотите.)

Answer 3

Многие мобильные устройства, чтобы разрешить приложению всплывающее браузер и вставьте крючки в браузер, который позволяет им наблюдать ключевые штрихи и тому подобное. Это может привести к регистрации ключа. Атака происходит следующим образом:

1. Приложение создает экземпляр браузера.
2. Приложение использует привилегированные API-интерфейсы браузера для добавления обработчиков ключевых событий на страницы, загруженные браузером.
3. Приложение заставляет браузер загружать URL-адрес, например, форму для входа в систему.
4. Использование предполагает, что политика браузера с одинаковым исходным кодом защищает введенные данные.
5. Приложение наблюдает и расширяет содержимое, возможно, включая пароль.

How can I launch Safari from an iPhone app?

How can I open a URL in Android's web browser from my application?

Answer 4

The Top Ten OWASP предназначен для веб-приложений, а приложения для Android отличаются.

OWASP, однако, имеет быстрорастущую мобильную систему, и в настоящее время они работают над Mobile Ten Ten. Вот список кандидат сверху десять на текущий год:

1. небезопасного Хранение данных
2. слабой стороны сервер управление
3. Недостаточного транспорта Защита слоя
4. стороны клиента Injection
5. Бедная авторизации и аутентификации
6. Неправильная обработка сеансов
7. Решения безопасности через ненадежные входы
8. Боковой канал данных Утечка
9. Разбитое Cryptography
10. Sensitive Раскрытие информации

Существует a wonderful set of slides, что объяснить это в деталях.

В дополнение к мобильной десятке OWASP Mobile я могу указать вам Application Security for the Android Platform, только что опубликованный O'Reilly в декабре 2011 года, в котором обсуждается существующий дизайн защищенных мобильных приложений на Android и дается обсуждение об унаследованных на этой платформе угрозах и как безопасно закодировать приложения, чтобы избежать их (отказ от ответственности: я автор этой книги :)).