Com sec android provider badge permission write

Разрешения Android 6.0 в защите и нападении

Содержание статьи

Каждый день в мобильных устройствах выявляют уязвимости, которые могут быть проэксплуатированы злоумышленниками. Они могут отправить СМС на платный номер, могут собрать большую базу данных контактов и продать ее, а могут и скомпрометировать конкретного человека. Удачная эксплуатация уязвимости обычно предполагает соблюдение целого ряда условий. Но ведь можно пойти и другим путем! Дать пользователю вполне нужное приложение (игрушку с птичками), у которого в манифесте будет записан список интересной нам информации на устройстве. В данной статье мы рассмотрим способы получения и сохранения важной информации с Android-устройства.

Архитектура ОС Android построена таким образом, что позволяет обмениваться разного рода информацией между приложениями. Приложению, работающему с картами, нужно местоположение, диктофону — доступ к микрофону. Таким образом, с виду все ясно и прозрачно.

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

Задолго до всем известного разоблачения я понимал, что игрушка со злыми птичками на твоем устройстве — это стукач, так как оно, помимо всего прочего, хочет читать идентификатор устройства и данные о вызовах. Простой вопрос «Тебе эти данные зачем?» обнажает истинные намерения ее создателей.

Пользователь при установке приложения ставится в положение «или разрешай все, что оно хочет, или останешься без программы». Только единицы пойдут в магазине искать приложение со сходной функциональностью, но с меньшими запросами (аналогов может вовсе не быть), поэтому у пользователей быстро входит в привычку жать «да-да-да» на все вопросы. Согласись, легко привыкать, когда за долгие годы офлайн-жизни у пользователей вырабатывался рефлекс автоматически подписывать многостраничные договоры, по принципу «ну, все же подписывают, наверное, тут ничего плохого, да и выход всего один — либо я подписываю тут, либо не получаю того, за чем пришел».

Если мы отберем все разрешения у приложения, ОС во избежание падения программы может просто отдать ему пустые значения. Можно обмануть приложение, подсунув ему заведомо ложные данные (местоположение Северного полюса) или просто нули. Например, приложение может спросить список контактов на устройстве, и разработчик предполагает в своей архитектуре, что он может быть пустым (совсем новое устройство). Тут даже и заподозрить нечего — и данные спасены, и приложение не сломалось.

На такие ухищрения приходилось идти вплоть до версии Android 6.0 Marshmallow. В ней появился новый механизм работы с разрешениями.

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

Читайте также:  Андроид буфер обмена очистка

Рассмотрим работу данного механизма на устройстве с версией Android 6.0.

Давай установим птичек, но перед первым запуском отберем у них все права. При запросе прав при установке из гуглплея мы видим, что targetSdkVersion у приложения меньше 23. Экран настроек говорит нам о несколько завышенных интересах создателей приложения.

Запрос прав при установке птичек из маркета

Хакер #204. Шифровальщик для Android

Как насчет того, чтобы немного их укоротить?

Забираем разрешения Вот так-то будет лучше

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

Теперь давай рассмотрим работу с обновленным приложением Skype. Вот перед нами часть манифеста «похожего» приложения. Список разрешений и требований из манифеста приложения вдохновляет:

Если бы только пользователи это видели.

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

У скайпа разрешений нет У скайпа разрешений совсем нет

Запустим приложение. Последовательно идут семь запросов.

Запрос скайпа 1

Последовательно отклоняем все запросы, и скайп превращается в интернет-чат :).

Постой, я сказал «в интернет-чат»? А почему он не спросил разрешения на доступ в интернет? А все потому, что разрешения делятся на две группы: обычные и опасные. Доступ теперь должны запрашивать только последние. Список обычных разрешений можно посмотреть тут. А вот — опасные разрешения (и их группы). Для создания запросов на разрешения есть подробные материалы: шаблоны использования запросов на доступ к разрешениям, рекомендации для доступа к разрешениям, а вот и полный список разрешений.

С теорией мы более-менее разобрались, теперь перейдем к практике.

Проникаем в список контактов (по-хорошему)

Обогащенные этим новым знанием, давай напишем небольшое приложение, в котором будем читать данные о контактах пользователя через запросы в интерфейсе и в сервисе. Как недавно выяснилось, некоторые приложения очень часто любят читать эти данные (оно и неудивительно — вдруг там что-то изменилось, а создатели «хороших» приложений и не знают).

Нажатием на кнопку мы проверяем версию ОС и, если она 23 и выше, делаем запрос на получение прав:

Диалог на запрос прав

После диалога в методе onRequestPermissionsResult нужно обработать ответ:

Читаем контакты в одну строчку с переходами на новую строку:

Показываем контакты в окне, при клике по окну оно скроется:

А вот результат работы чтения контактов:

Забыл взять контакты у совы

Проникаем в список контактов (по-плохому)

Теперь проделаем то же самое, но в сервисе, как и положено плохому приложению. Сервис никаких запросов слать не будет, а будет пытаться просто в лоб читать контакты.

Запуск сервиса сделаем по событию подключения к Wi-Fi .
Код сервиса:

Если у приложения есть права, то сервис покажет Toast сообщение со списком контактов, если прав нет — вызовет ошибку с сообщением. Теперь исследуем поведение приложения, если выставить ему targetSdkVersion ниже 23.

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

Заключение

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

Источник

By default my expo app includes a lot of permissions #10206

Comments

LuD1161 commented Sep 16, 2020

When I run expo build:android -t apk the built app has a lot of permissions by default.

This is my app’s AndroidManifest.xml :

I’ve set permissions to an empty array as following :

I’ve only one file app.js which gets an Expo token and displays on the screen.
App.js

export default App; «>

Other Details

  • Expo SDK: 38.0.0
  • Release channel: default
  • Workflow: Managed

Do I need to eject from expo to sort this 🤔 ?

The text was updated successfully, but these errors were encountered:

LuD1161 commented Sep 16, 2020

LuD1161 commented Sep 16, 2020

I think this was/should’ve been fixed here : expo/expo-cli#2458
But this has still crept in, not sure exactly if that did really solve this issue.

brentvatne commented Sep 16, 2020 •

edit: sorry i didn’t fully read the issue before responding, this is a very common issue for folks to post without reading that docs page and you actually read it 🙂 i believe that the changes that @byCedric added in the expo-cli commit are not yet deployed, they will roll out with sdk39.

LuD1161 commented Sep 16, 2020 •

@brentvatne can I try those changes, like pull the latest branch ( it seems to be merged in the master ) ?
If not what’s the timeline for sdk39 🤔

LuD1161 commented Sep 16, 2020

This seems to have the commit merged.
But is this an issue with expo-cli only ?

LuD1161 commented Sep 16, 2020

LuD1161 commented Sep 16, 2020

and got to this :

However I haven’t compiled a package before so I am kinda confused if this is the correct way to do that.
I’ve cloned this from master

If not can you suggest a better alternative, ejecting ( I don’t want that currently ) ?

byCedric commented Sep 16, 2020 •

@brentvatne is right, we made some changed but that will be shipped when we roll out SDK 39. If you absolutely need to remove some of the permissions, your best bet would be ejecting and manually exclude some of the permissions from your AndroidManifest.xml . Be aware, you have to build it yourself after doing this.

You can always «revert» back to the managed flow though, so If you are going for this approach I would recommend not committing this to the main branch.

Hope this helps!

brentvatne commented Sep 16, 2020

@LuD1161 — the code in the commit you referenced runs on our build machines, and just incidentally happens to also be included in expo-cli due to the way the package is currently structured. there isn’t anything that you can do on your machine to modify this on the build service currently. we’re working on getting sdk 39 out so if you can deal with having these permissions in your app for a week or two then you should be able to take advantage of the improvements soon enough

LuD1161 commented Sep 17, 2020 •

Hi @brentvatne and @byCedric
Extremely glad for the quick response.
I did expo eject and followed the instructions.

I had one doubt here :

    After running yarn android which produces a debug app and also with ./gradlew buildRelease ( after following through this here ) I got an app with the same size as previously

25MB
I understand it’s because of unimodules . so how should I not include those 🤔

Do I need to change the dependencies here 🤔 ?

This is the installation process where I see the unimodules getting installed

supryan commented Sep 21, 2020 •

This is actually a more critical issue than is being discussed here. We are developing an app for children and the automatic including of location permissions is preventing us from releasing an app on the Google Play Store because location permissions need to be removed in a target audience of 13 years and younger.

Ejecting still seems to include the expo-location package even though it’s not included in my npm modules. This really needs to be fixed.

brentvatne commented Sep 21, 2020 •

Ejecting still seems to include the expo-location package even though it’s not included in my npm modules. This really needs to be fixed.

you can remove the permission and the package will have no impact on permissions in your app. but you can also remove the package by excluding it from autolinking, as described in https://docs.expo.io/bare/installing-unimodules/ under «Need to exclude some unimodules that are being automatically linked?»

This is actually a more critical issue than is being discussed here. We are developing an app for children and the automatic including of location permissions is preventing us from releasing an app on the Google Play Store because location permissions need to be removed in a target audience of 13 years and younger.

can you elaborate on why removing the permissions as described here is insufficient for your needs?

supryan commented Sep 21, 2020 •

@brentvatne thanks for the quick reply! We do have permissions: [] set in the app.json but unfortunately this still includes android.permission.ACCESS_BACKGROUND_LOCATION automatically through the expo build process. We do not have any location functionality nor have we installed expo-location . This permission is the main reason we can’t get our app released currently.

brentvatne commented Sep 21, 2020

ah, got it! we are releasing sdk 39 very soon where we revamped the permissions on android and it should be possible for you to opt out of that permissions now. if all goes well we may release this today or tomorrow

supryan commented Sep 21, 2020

@brentvatne amazing thank you so much!

supryan commented Sep 23, 2020 •

@brentvatne can confirm there are no more location permissions automatically bundled in SDK 39! However, our app still got rejected for the same reason when target audience You have to remove location permissions. ? Checking the bundle, I see some location stuff under «Features» but not as a permission. Any idea what’s up? We reached out to Play Store support as well.

ridgeO commented Sep 28, 2020

@supryan, running into the same issue with my latest app update. Did you find a solution?

byCedric commented Sep 29, 2020 •

Just double-checked this by creating an Android APK using $ expo build:android -t apk on a simple SDK 39 project. I’ve added the permissions with the android.permissions = [] in the manifest and without. If you are still having issues with this, please send us an email at secure@expo.io containing the following info:

  • App manifest
  • full app name (+ release channel, if you use them), e.g. @bycedric/myawesomeapp
  • The list of permissions you get from the APK, you can use the aapt tool locally.

With that, we can try and see what’s going on with your app.

Example permissions

Using bare instead of managed?

You should be able to control all of the permissions from the AndroidManifest.xml . Read more on the docs.

Hope this helps!

supryan commented Sep 30, 2020

@ridgeO we are still experiencing this issue unfortunately but I did follow up with @byCedric and will report back if I hear any new information.

igorbrandao commented Oct 7, 2020 •

Hi everyone! I am having this issue as well. We just recently upgraded from SDK 36 to SDK 38 (about a month ago) and never realized that our app requested background location permissions. We do use location features, but they are needed only when our app is foregrounded.

And if the user grants that, we use it on two occasions:

  1. getCurrentPositionAsync and reverseGeocodeAsync of expo-location to display the country and city of the user
  2. Get their current coordinates also with getCurrentPositionAsync and show a centered on their location

Can we opt out of background location permission in SDK 38 by setting android.permissions to [«ACCESS_COARSE_LOCATION», «ACCESS_FINE_LOCATION», . ] or that only works on SDK 39? Also, what is the difference between FINE and COARSE locations? Our code is Location.getCurrentPositionAsync(< accuracy: Location.Accuracy.Balanced >) , so which category does it fall in (FINE, COARSE or both)?

It would be very helpful not only if we had an expo command to list all currently requested permissions (just so we don’t have to fiddle with adb ), but also if we could have a bit clearer expo docs (currently here) on how to get rid of background location if you want to have only foreground location on android.

brentvatne commented Oct 7, 2020

@igorbrandao — we revamped permissions in sdk 39 — for your concern about background location see this forums post. you will only be able to do that on sdk-39 and greater.

for information on fine vs coarse, check out the android permissions documentation — anything that uses gps will need fine, if you want something approximate based off of wifi/cellular data. if you want it to be remotely accurate you should use gps fine location.

Источник

Читайте также:  Сяоми плохо ловит сеть что делать андроид
Оцените статью