Реклама
   Телефоны
   МР3-плееры
   ПК
   Периферия
   Гаджеты
   Мультимедиа
   Интересности
   Фото и Видео
   Моддинг
   Новости
   Прототипы

OWASP Mobile Top 10 за 2016 год: Неправильное использование платформ iOS и Андроид



Современные онлайн приложения для мобильных телефонов испытывают возрастающее давление со стороны хакеров и вредоносного ПО, как на iOS, так и на Android. Несколько громких случаев продемонстрировали, насколько легко хакеру взломать мобильное приложение, и как небрежно относятся к безопасности в крупнейших компаниях мира. Мы считаем OWASP Mobile Top 10 ключевым фактором, чтобы помочь разработчику мобильных приложений понять и улучшить безопасность своего приложения.
Открытый проект безопасности веб-приложений (Open Web Application Security Project) — это онлайн сообщество, издающее бесплатное вики, содержащее статьи, документацию и образцовые практики, относящиеся к безопасности веб-приложений. OWASP Mobile Top 10 ориентирован на мобильные приложения, причем как на клиентскую архитектуру, так и на серверную инфраструктуру. Не так давно была опубликована окончательная версия 2016 года, хотя работа над ней и не закончена полностью. Мы решили заполнить некоторые пробелы примерами, которые разработчики могут внедрить на своих приложениях прямо сейчас.

M1 Неправильное использование платформы



В OWASP Mobile Top 10 риски мобильных приложений пронумерованы от M1 до M10. В начале списка находится неправильное употребление возможностей платформы и неудачное использования средств безопасности платформы. Риски касаются в частности Touch ID, Keychain, намерений (intents) Android и прав доступа платформы.

OWASP Mobile Top 10: M1 – iOS



Touch ID

Touch ID для iOS дает пользователю возомжность разблокировать свой айфон при помощи отпечатка пальца вместо кода. Он также создает прецедент для разработчика, приложение которого будет идентифицировать пользователя при помощи Touch ID.

Существует два пути использования Touch ID в приложении:
посредством Keychain Access Control Lists (ACLs)
при помощи фреймворка LocalAuthentication для идентификации пользователя
Фреймворк LocalAuthentication уязвим для обхода либо через модификацию локальной проверки во время выполнения, либо через исправление двоичного кода путем переопределения LAContext evaluatePolicy:localizedReason:reply:. В iOS этот метод используется для проверки присутствия пользователя перед тем как вернуть элементы Keychain в приложение.

Как исправить?

При использовании Touch ID для авторизации на уровне приложения необходимо вместо этого прибегнуть к Keychain для хранения секреты приложения с присвоенным ACL. Этот ACL должен включать политику kSecAccessControlUserPresence, которая будет усилена операционкой.

Keychain

В iOS Keychain дает пользователю безопасное хранение пасскодов, ключей и сертификатов. Безопасность достигается за счет шифрования данных перед тем, как поместить их в файловую систему, тем самым снимая с разработчика задачу внедрения собственной системы шифрования. Система также контролирует, какие именно приложения имеют доступ к элементам keychain через Keychain Access Groups (для элементов, синхронизируемых через iCloud) и Access Control Lists (ACLs).

Элементы keychain в целом разблокируются при разблокировнии устройства при помощи либо пасскода пользователя либо TouchID, в зависимости от настроек и возможностей устройства. Следуя этому шаблону, Keychain предоставляет прозрачную авторизацию; таким образом (после разблокировки keychain), пользователю не надо отдельно авторизоваться в любом сервисе, пароль которого храниится в keychain.

Существует несколько способов взломать и расшифровать Keychain. Средства управления Keychain бесполезны, когда устройство взломано, и позволяет другим приложениям читать элементы Keychain. Старые устройства, такие как айфон 4, так же уязвимы для иксплойтов BootROM, когда к устройству есть физический доступ.

Как исправить?

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

- kSecAttrAccessibleWhenUnlocked
Элемент Keychain доступен только после разблокировки устройства
Ключи класса защиты данных для расшифровки элементов keychain загружаются в память только при разблокировке устройства, а ключи шифрования автоматически удаляются через 10 секунд после того, как устройство заблокировано
Это значение по умолчанию для элементов keychain, добавленных без явного указания константы доступа
- kSecAttrAccessibleAfterFirstUnlock
Элемент Keychain доступен только после первой разблокировки устройства до перезагрузки
Ключи класса защиты данных для расшифровки элементов keychain загружаются в память только после того, как пользователь разблокирует устройство после перезагрузки, и ключи остаются в памяти до следующей перезагрузки устройства
- kSecAttrAccessibleAlways
Элемент Keychain доступен даже если устройство заблокировано
Ключи класса защиты данных для расшифровки элементов keychain всегда загружены в память
- kSecAttrAccessibleWhenUnlockedThisDeviceOnly
Элемент Keychain доступен только если устройство разблокировано и элемент нельзя передать на другое устройство.
- kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly
Элемент Keychain доступен после первой разблокировки устройства и элемент нельзя передать на другое устройство.
- kSecAttrAccessibleAlwaysThisDeviceOnly
Элемент Keychain доступен даже если устройство заблокировано и элемент нельзя передать на другое устройство.

В целом, если возможно, надо зашифровывать элементы Keychain при помощи констант ThisDeviceOnly, в противном случае данные будут видны другим устройствам через бэкапы iTunes или Keychain iCloud.

Известные на данный момент иксплойты позволяют рекомендовать разработчикам использовать эти константы для шифрования конфиденциальных данных на уровне приложения. Один из способов — это авторизация на уровне приложения и использования пасскода для шифрования данных, которые буду храниться в Keychain.

OWASP Mobile Top 10: M1 – Андроид



Intents (намерения)

На платформе Андроид Intents используются разнообразно:
- для начала Активности, в координации с другими программами (например, просмотр веб-страницы)
--при помощи метода Context startActivity()
-как вещание, чтобы информировать заинтересованные программы об изменениях или событиях
--при помощи семейства методов Context sendBroadcast(), sendStickyBroadcast(), и
-sendOrderedBroadcast()
--как способ начать, остановить или общаться с фоновыми сервисами
при помощи методов Context’s startService(), stopService(), и bindService()
- получить доступ к данным через ContentProviders, например, контактам пользователя
--при помощи методов Context getContentResolver() или Activity’s managedQuery()
- как колбэки для обработки событий, например, асинхронный возврат ошибки или результата при помощи
PendingIntents передаваемые с клиентов на сервер через Binder interfaces.

Неправильное использование intents может запускать уязвимые активности, взаимодействовать с другим приложениями и вести к утечке данных.

Как исправить?

Поскольку intents посылаются другим компонентам Андроид, таким как Активности, Сервисы и BroadcastReceivers, эти компоненты могут быть public или private. Чтобы избежать этого, выставляйте эти компоненты в манифесте приложения как android:exported=false.

android:name=".RSSPullService"
android:exported="false"/>


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







Сниффинг намерений (Intents)

Вредоносное приложение Андроид может зарегистрироваться для получения вещания или скрытых intents от других приложений. Вредоносные приложения таким образом могут считывать данные, передаваемые с intent, в том числе и конфиденциальные. Такой процесс называется сниффингом намерений, и при наличии легкодоступных средств реализовать его весьма просто.
Например, если приложение открывает веб-браузер с URL адресом, вредоносное приложение может считать данные из URL адреса. Или же приложение может передать набранные пользователем данные аккаунта в намерении, чтобы запустить авторизованные активности.

Как исправить?

Всегда используйте экплицитные intents вместо того, чтобы передавать данные между приложениями в виде вещательных (broadcast) intents. Для создания экплицитного intent убедитесь, что вы определили имя компнента для объекта Intent:
Наш Intent эксплицитно запускает класс DownloadService в нашем приложении

Intent downloadIntent = new Intent(this, DownloadService.class);
downloadIntent.setData(Uri.parse(fileUrl));
startService(downloadIntent);


Также нужно присваивать android:exported значение false для любых активностей или сервисов, которые ваше приложение вызывать не должно:

android:name=".RSSPullService"
android:exported="false"/>


Небезопасные права доступа к файлам

Небезопасные права доступа к файлам — одна из самых распространенных ошибок, когда речь идет об использовании возможностей платформы Андроид для хранения данных. Использование прав доступа ‘world readable’ and ‘world writeable’ может привести к утечке данных и обнаружить приложение для хакеров, которые могут переписать данные приложения.

Особенно рискованно, когда динамически загружается код из файлов извне APK вашего приложения, который может оставлять приложение открытым для инъекции кода. Динамически загружаемый код исполняется с теми же правами доступа, что и остальная часть приложения, так что он должен загружатсья из проверяемого источника и быть доступным только для основного кода приложения.

Как исправить?

Следуйте принципу минимальных привилегий, когда присваиваете права доступа и избегайте таких прав доступа как MODE_WORLD_READABLE или MODE_WORLD_WRITEABLE. Эти права не органичивают доступ конкретных приложений и никак не контролируют формат данных.

Вместо этого для совместного доступа к файлу нескольких приложений используйте ContentProvider, который не только реалиует права read и write, но и динамические права доступа в каждом конкретном случае. Можно также зашифровать файлы при помощи ключа, хранящегося в KeyStore и защитить его паролем пользователя, который не хранится на устройстве.



23.06.17


Просмотров: 120
Пожалуйста, оцените статью:  

Понравился пост "OWASP Mobile Top 10 за 2016 год: Неправильное использование платформ iOS и Андроид"?
Поделись с друзьями:






Комментарии
Еще нет комментариев
Добавить комментарий

Комментарии, содержащие мат, будут удаляться

Войти! | Регистрация | Напомнить пароль
:

:









Мобильные телефоны

Nokia
Sony Ericsson
Samsung
Motorola
iPhone
HTC
LG
Meizu
Highscreen

Компьютеры / Ноутбуки

Acer
Alienware
Apple Macbook
Apple iMac
ASUS
Fujitsu
Gateway
Dell
Lenovo
HP
Sony Vaio
Toshiba


Разделы:

Вход на сайт
Имя:

Пароль:




Забыл пароль?


 



Календарь
  Сентябрь 2017  
пн
вт
ср
чт
пт
сб
вс
    123
45678910
11121314151617
18192021222324
252627282930 

РЕКЛАМА НА САЙТЕ

Рассылка 'Mobbit.info - ежедневное обозрение новинок мобильного мира.'

экспорт rss


Читать в Яндекс.Ленте



Яндекс цитирования

Рейтинг@Mail.ru